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();
}

I’ve been quiet lately, mostly because I have been very busy with work. These last couple of months has been intense and filled with SOAP, web services and the SOA paradigm.

After digging into Indigo and preparing for my overview presentation, I went strait on to designing and building a new version of our integration infrastructure. The solution relies heavily upon on WSE 2.0 and this has provided me with some interesting challenges. Naturally, it also borrows some concepts and ideas from Indigo.

Expect more details on my WSE 2.0 experience as I get both them and my mind organized.

After a few months of insecurity I finally got confirmation that I’ll be attending the Microsoft Professional Developers Conference 2003.

I’m really looking forward to diving into the new distributed application platform, the next version of Windows, SQL Server and Whidbey, and of course seeing some of the industries finest techies in action.

And with a little bit of luck there will be some very interesting discussions and bloggers events.

In short; I just can’t wait!

In a rather interesting turn of events I find myself enjoying a much deserved 6 weeks long vacation in Melbourne, Australia.

I’m visiting a long time friend of mine, and combining a piece of local culture with a rather fair amount of computer related research and some of the world’s finest red wine.

I guess this makes me wonder if any .Net bloggers out there are keen on grabbing a computer related beer in the heart of Melbourne.

Clemens enlightened the audience at the Norwegian Visual Studio. NET 2003 launch event, SOAP 1.2 became a W3C Proposed Recommendation and Mono got C# Iterators. I guess this makes for an another interesting .NET month :)

Visual Studio.NET 2003 RTM is available trough MSDN Subscriber Downloads! Go fetch :)

People are publishing their instant messaging addresses, and I thought I would throw mine onto the pile. You can reach me through Windows/ MSN Messenger on messenger@morty.info. I’m available for discussions, questions, rants and laughs, or if you just want to share an online beer (b).

Brad Adams asks an interesting question regarding code samples and whether to use the native type names of the programming language or the more generic BCL type names.

My view on this is that once you choose to write an example or a code snippet in a specific programming language for whatever reason; you should adapt all of the features of that language. Both with regard to coding style, custom type names and special constructs (for instance the using statement in C#).

As of today both VB.NET and C# have pretty much the same language features, but if we look to the future we can see that the C# language is evolving (generics, iterators, anonymous methods, partial types). And I assume that VB.NET will evolve to better suit its users much in the same way. And more languages are coming. As the language differences increase it will start to look somewhat unnatural if you ignore its features, as I believe the type keywords to be.

In my experience most C# programmers are using the C# specific keywords and not the BCL types, I know I do. I guess I’m getting a weak pseudo code feeling when I see the use of BCL types in samples.

If you want to write generic examples that appeal to all user groups you should probably use a pseudo language, and I guess that’s not really a tempting options. If you have made a language decision, then use the language in a way that its users are most familiar with. Make the code samples feel natural, and appeal to their sense of best practice.

I guess this is a bit wider than the original questions, but I just wish there were more using statements in C# samples…

It has been some time since my last update. I guess there isn’t much to say except I’ve been really busy trying to combine downhill skiing with a lot of research and work. On top of that I’m squeezing in time to complete a couple of slide decks about message oriented architecture and GXA in dynamic environments.

I came across SIMP (Secway's Instant Messenger Privacy) from Secw@y here the day. It is a small utility designed to secure your MSN Messenger conversations providing both encryption and authentication services, and best of all it is free for both home and business use.

Usually I’m not a very paranoid person, but I enjoy privacy technologies as much as the next guy and this product is definitely worth a try.

Andreas Eide blogs about side by side issues with VS.NET 2002 and VS.NET 2003.

So, I have this project developed in Visual Studio .NET 2003 that I want to use at the customer site. At first I only needed the executables, so I set up Visual Studio .NET 2003 to compile to v1.0.3705 of the framework. This worked just fine. But now I want to use the source code at the customer site. I can’t open the VS.NET 2003 solution with VS.NET 2002. It says that the file is not a valid solution file. And I have found no way in VS.NET 2003 to save the solution in 2002 format.

This got me thinking about an article I read over at www.codeproject.com, so I did a quick search and found this tool; A Utility to Convert VS.NET 2003 Project Files.

Even though it is fairly annoying not being able to do a test compile of your current solutions without converting all the solution, project and resource files, this tool may be able to help ease some of the pain.

At the risk of relighting an old debate I feel that I need to type down a few thoughts on the topic of .Net language interoperability. Over the last couple of years I’ve been in countless .Net discussions, and quite a few of them have at one point or another touched this specific topic. Either it is a Java supporter claiming that this feature is effectively useless and will eventually create chaos or the never ending debate about whether C# or VB.NET is the wave of the future. This over-discussed yet underappreciated topic has none the less inspired me to publish a slightly different point of view.

I feel that a large part of the people I talk assume that language interoperability is all about making the right decision about what general purpose programming language to use, or if you read the marketing slogans; not making that decision at all. And I guess in a lot of cases it probably is. Yet it seems to me that one of its most appealing opportunities is effectively ignored.

The interesting thing about language interoperability is, in my opinion, not about making a choice between general purpose programming languages, but rather about all the cool special purpose languages that are or will be available. Today we have a regular expressions compiler, and soon we will probably have a XSLT compiler. Then we will most likely have the database languages, the reporting languages, the mathematical and scientific languages and of course the process and abstract state machine languages. And all of these different compilers will transform their various input formats into verifiable and easily accessible IL modules.

To me this is the true beauty of the language interoperability feature. It provides you with the opportunity to utilize languages that are designed to greatly simplify specific tasks, and then effectively integrating these languages with the general purpose programming language of your choice. This is what makes me hit the download button every time I see a new managed compiler. And quite honestly, whether you choose MC++, C# or VB.NET to do your work is no longer exiting or refreshing conversation material.

The HTML Working Group has released the third Working Draft for XHTML 2.0!

All we need now is for Visual Studio and Internet Explorer to officially support XHTML versions 1.0 and 1.1 ;)