Navigation

Search

Categories

On this page

Mono Roadmap Updated
Enforcing Xml Schema Validation

Archive

Blogroll

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

RSS 2.0 | Atom 1.0 | CDF

Send mail to the author(s) E-mail

Total Posts: 83
This Year: 0
This Month: 0
This Week: 0
Comments: 20

Sign In

# Wednesday, 28 April 2004
Mono Roadmap Updated
Wednesday, 28 April 2004 18:56:42 UTC ( Mono )

The mono team has put up an updated roadmap for the mono project.

Beta 1: May 4th - Feature Complete

Beta 2: June 1st

Mono 1.0: June 30th

I guess this means that if they stay on track we will have a fairly stable multiplatform CLR and BCL this summer. The mono platform still lacks several critical enterprise features, but it is interesting to see what they have accomplished so far.

Comments [0] | | # 
# Sunday, 25 April 2004
Enforcing Xml Schema Validation
Sunday, 25 April 2004 15:26:08 UTC ( General )

Validating xml documents is one of the more common tasks when building extensibility points, integration infrastructure or enabling configuration support. The .Net Framework provides a type called XmlValidatingReader to help you with this task. There are however a few pitfalls you should be aware of if you want to be certain that an xml instance conforms to the provided xml schema.

Always Define a Validation Event Handler

The xml validation system uses severity levels to indicate the level of validation failure. There are two severity levels available; namely XmlSeverityType.Error and XmlSeverityType.Warning. The interesting thing is that unless you specify your own validation handler only the severity level of XmlSeverityType.Error will cause an exception to be thrown; all warnings are ignored.

This may not seem like a big issue until you realize that “missing schema for provided type” is a warning and not an error. Therefore, unless you have a schema loaded for the xml instance namespace, anything goes.

When you provide your own validation handler, you can intercept both severity levels and act accordingly. A simple default could be to throw the exception provided within the ValidationEventArgs parameter, as you will see in the sample below.

Always Specify a ValidationType

The default ValidationType is ValidationType.Auto, which means that unless you have provided a schema for the instance namespace, it will assume ValidationType.None and no validation takes place.

If you are using Xml Schemas, you should set this to ValidationType.Schema.

In Conclusion

The common theme here is that vanilla validation only works if you happen to have the same namespace in your xml instance and xml schema documents. Unless your application explicitly checks the namespace of the xml instances it processes, you could easily submit whatever xml document you wanted as long as it uses a different namespace than what the schema expects.

You will find a code snippet below that incorporates this advice, and hopefully gives you some ideas on how to address these issues in you code.

Code Snippet

static void ValidationHandler(object o, ValidationEventArgs args)
{
 throw args.Exception;
}

static void Validate(XmlReader reader, XmlSchema schema)
{
 XmlValidatingReader validatingReader = new XmlValidatingReader(reader);
 validatingReader.ValidationEventHandler += new ValidationEventHandler(ValidationHandler);
 validatingReader.Schemas.Add(schema);
 validatingReader.ValidationType = ValidationType.Schema;
 while (validatingReader.Read());
 validatingReader.Close();
}
Comments [0] | | #