What Would You Like To See in System.Xml in Orcas/Longhorn?

I'm in the end stages of doing the spec work for the various components in the System.Xml namespace  I am responsible for in the Whidbey betas. After the 4th of July holidays we plan to start doing initial brain storming for what feature work we should do in Orcas/Longhorn. I thought it would be valuable to have various users of XML in the .NET Framework suggest what they'd like us to do in the Orcas version of System.Xml. What changes would people like to see? For example, I'm putting Schematron and XPathReader on the 'nice to have' list. No idea is too unconventional since this is the early brainstorming and prototyping phase.

Caveat: The fact that a technology is mentioned as being on our 'nice to have' list or is suggested in a comment to this post is not an indication that it will be implemented in future versions of the .NET Framework.

Comments (16)
  1. shawn says:

    I’d personally be interested in seeing support for XInclude, or similar functionality under another umbrella.

  2. Unsorted out of the blue list:


    XInclude (I hope it will reach Rec stage this year), XML Base

    Sure XPathReader.

    What about moving EXSLT.NET to the core XPath/XSLT engine?



    XSL-FO 🙂

  3. Luc Cluitmans says:

    – Make subclassing XPathNavigator a bit easier.

    Rationale: I have found that building custom subclasses of XPathNavigator to expose legacy file formats as if they were XML is very fruitful. However, subclassing XPathNavigator quite often involves doing the same things over and over again.

    – Fix the XPathNodeIterator issue – or is that already fixed in Whidbey?

    Rationale: To have custom XPath/XSLT functions return a node set, the specs hint that the function should return an XPathNodeIterator instance. Sadly, many parts of the XPath/XSLT engine actually require a nonpublic subclass of XPathNodeIterator instead (its name currently escapes me; was it ‘ResettableXPathNodeIterator’ ?). Exslt.NET for instance works around this issue by using a rather ugly reflection based hack to access classes that are internal to System.xml.dll (IIRC).

    – A design issue: Please, please keep the various XML technologies where they belong. Why do I have to use parts of XSLT engine, and look at the XSLT documents to make XPath extension functions? Yesterday I finally installed the Whidbey May CTP, and immediately went investigating XQuery. Why does it seem to be integrated with all kinds of SQL technologies? Of course, I see that XQuery and SQL integration is important for microsoft’s SQL view. But the way it is now, I really get the feeling that microsoft is forgetting that XQuery is perfectly well suited to be applied to pure XML data (including XPathNavigator based data), without using any database at all. Note that it is perfectly well possible to use the XQuery stuff without any SQL, but the fact that the docs (as far as they exist) are rather SQL-centric, and the fact I need to reference an SQL-related assembly (system.data.sqlxml.dll) to get the XQueryCommand functionality makes me suspect that MS is viewing XQuery far too much as a Yukon-related technology instead of viewing it as a technology with its own merits.

  4. A simple way to take an XPathDocument and create an XMLDocument from it. This may be in ASP.NET 2.0. If so, then "Thanks!".

  5. Steve Perry says:

    I would like to see an easy way to tell the xml parser to ignore a embeded schema and validate the document using an external schema file. The rational is that I don’t trust the XML that came from a third party to conform to the schema I have set up.


  6. This may be a bit off-topic, but have you guys given any thought about what is beyond MSXML for Internet Explorer? Any plans to see managed code meet the client-script world? Or is this out of your jurisdiction?

  7. Talk with Chris Lovett and create a MS SgmlReader that support HTML 4.0 and also XHTML.

    That would be nice, if possible.

  8. Darn, I almost forgot about the actual topic.

    What I would like to see in System.Xml is a some kind of XML content assembly framework, maybe not CAM, maybe just an assembling reader of some sort, but just enough to build upon.

  9. I’m interested in Semantic Web. <br>

    Been searching for native MS tools for rdf, onthology and building semantic web

    Would love to see native support for rdf

    ontology validation

    A little off track

    Is X# still a mystery. Any linking with XML


  10. Ronald Wood says:

    Please support XSLT 2/XPath 2. I’ve haven’t looked much at XQuery, but I can easily understand its utility. However, we still use XSL for transforms on highly heterogenous sources with diverse outputs (HTML, plain text, email, PDFs through XSL-FO).

    I also agree that we should be able to validate XML against any arbitrary schema. This was possible with MSXML and was taken out in the .NET API. This is very useful for XML that is part of internal workflow.

  11. My wish:

    – SgmlReader built-in

    – XPathReader built-in

    – XInclude built-in

    – EXSLT built-in

    – XPath 2.0 API (stand-alone, outside XQuery, like the good old XPathNavigator.Select?)

    – RelaxNG

    – Schematron

    – Lighweight streaming transformations API (to avoid full XSLTs)

    – RDF core

    – Maybe RDF query

    Chris Darnell, if you have an XPathNavigator from an XPathDocument, you can load an XmlDocument using the XPathNavigatorReader: http://weblogs.asp.net/cazzu/archive/2004/04/19/115966.aspx.

  12. Robbie Coenmans says:

    XQuery 1.0 and XPath 2.0 Full-Text search functionality: http://www.w3.org/TR/2004/WD-xquery-full-text-20040709/

  13. xml training says:



    XPath 2 & XSLT 2 with FULL-TEXT search capabilities


    And most importantly: XQuery

  14. nCandy says:

    I definitely have to agree with Robbie… XQuery!

Comments are closed.

Skip to main content