re: The world has moved on, have you? Xml APIs you should avoid using.

Pawel — Mon, 31 Oct 2011 06:17:12 GMT

@Simon:

Thanks for reading the blog post. I appreciate your taking the time to express your opinion in a thoughtful way. One of the intents of providing such guidance as in our last post is to trigger valuable comments from outside Microsoft such as yours. Such input will help us in shaping this to be a better API in the future.

One of the main reason why we have two kinds of APIs for the doing same thing is compatibility. It was extremely important that applications written for .NET Framework 2.0 continued to work on .NET Framework 3.0 and 3.5. since both .NET Framework 3.0 and 3.5 were in-place updates. This means that once you installed a newer version of the .NET Framework on your machine all applications compiled against .NET Framework 2.0 would automatically run against the newer version you just installed. This excluded the possibility of removing any API in .NET Framework 3.0 or 3.5. From this point of view .NET Framework 4 was the first release we could potentially remove the APIs deprecated in .NET Framework 2.0. Unfortunately even in .NET Framework 4 there are still some classes not owned by the Xml team (e.g. System.Web.UI.WebControls.Xml) that use the obsolete APIs.

There were two main issues with XmlTextReader and XmlTextWriter classes. These are mentioned in security sections of the standard MSDN help for these classes msdn.microsoft.com/.../system.xml.xmltextreader.aspx and msdn.microsoft.com/.../system.xml.xmltextwriter.aspx as well as in specific MSDN articles around System.Xml security as mentioned below :

- XmlTextReader parses DTD by default which can lead to DTD entity expansion DoS attacks if the DTD comes from an untrusted source - msdn.microsoft.com/.../ms172415.aspx

- XmlTextWriter allows for writing invalid Xml documents e.g. by not checking whether the characters written by the writer are valid Xml characters - msdn.microsoft.com/.../ms172416.aspx

Changing any of the above behaviors would break existing applications people may not even be able to fix (e.g. the source code has been lost). On the other hand not fixing these issues feels wrong. You can find more details about improvements introduced to the XmlReader and XmlWriter classes here:

- New features in the XmlReader class msdn.microsoft.com/.../8459257a(v=VS.90).aspx

- New features in the XmlWriter class msdn.microsoft.com/.../sfk4704d(v=VS.90).aspx

Moving from XmlTextReader and XmlTextWriter to XmlReader and XmlWriter respectively is relatively easy for applications that use classes shipped with .NET Framework to read and write Xml documents which. I believe this is the way the vast majority of applications use Xml reader and writer APIs.

However if an application is using a reader/writer derived from XmlTextReader/XmlTextWriter then I agree that it may require a lot of effort to move. In any case it is still up to the user to decide whether to move or not. If the user decides that the benefits (e.g. character checking) won’t justify the cost then s/he may stick to the old APIs. In case of new applications - the msdn documentation for XmlTextReader and XmlTextWriter (and XmlReader and XmlWriter) for .NET Framework 2.0 and up recommends using XmlReader and XmlWriter APIs and creating instances using factory methods. Indeed, customizing the behavior of XmlReader and XmlWriter requires a bit more work than just deriving and overriding selected methods as you need to wrap the XmlReader/XmlWriter and forward the calls (as described www.tkachenko.com/.../000585.html) but it gives you all the functionality that is missing in XmlTextReader and XmlTextWriter classes.

re: The world has moved on, have you? Xml APIs you should avoid using.

Scott Brickey — Wed, 19 Oct 2011 15:39:41 GMT

The world has moved on... to XSLT 2... when can we expect MS to catch up?

re: The world has moved on, have you? Xml APIs you should avoid using.

Santosh Arisetty — Fri, 14 Oct 2011 19:07:11 GMT

Decent explanation, why few of the API's were made obsolete. Of course we need to change the code accordingly to ensure better support. Keep posting.

re: The world has moved on, have you? Xml APIs you should avoid using.

Simon Cropp — Thu, 13 Oct 2011 13:52:07 GMT

In response simoncropp.com/how-to-mismanage-an-api

re: Xslt 1.0 biggest issues (kind of) solved

Santosh Arisetty — Wed, 12 Oct 2011 19:36:25 GMT

When can we expect XLST 2.0 support in core framework of .Net ? Its been a long time that XLST 2.0 is released. Hopefully it will be in place soon.

re: The world has moved on, have you? Xml APIs you should avoid using.

Ehsan Mohammadi — Mon, 10 Oct 2011 10:02:48 GMT

Thanks

re: The world has moved on, have you? Xml APIs you should avoid using.

John — Mon, 10 Oct 2011 00:21:41 GMT

"the world has moved on" from XML to Json :-)

re: Xslt 1.0 biggest issues (kind of) solved

Lionel — Sun, 09 Oct 2011 18:06:13 GMT

Thanks!

As you said, having workarounds rather than real solutions is almost never ideal, however. Maybe you could support XSLT 2.0 in the not-too-distant future?

re: Xslt 1.0 biggest issues (kind of) solved

Justin — Sun, 09 Oct 2011 15:44:48 GMT

Or use XQSharp which is a native .Net XSLT 2.0 processor:

http://www.xqsharp.com

You guys have really dropped the ball with XSLT 2.0.

re: Xslt 1.0 biggest issues (kind of) solved

Jonathan Allen — Sun, 09 Oct 2011 15:23:43 GMT

Yea, I think I'll just use Saxon for XSLT work.

http://saxon.sourceforge.net/

Microsoft XML Team's WebLog - All Comments

re: The world has moved on, have you? Xml APIs you should avoid using.

re: The world has moved on, have you? Xml APIs you should avoid using.

re: The world has moved on, have you? Xml APIs you should avoid using.

re: The world has moved on, have you? Xml APIs you should avoid using.

re: Xslt 1.0 biggest issues (kind of) solved

re: The world has moved on, have you? Xml APIs you should avoid using.

re: The world has moved on, have you? Xml APIs you should avoid using.

re: Xslt 1.0 biggest issues (kind of) solved

re: Xslt 1.0 biggest issues (kind of) solved

re: Xslt 1.0 biggest issues (kind of) solved