Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2
We are in the process of locking down System.Xml for Beta 2 of the .NET Framework 2.0 and Visual Studio 2005. In the past few months we have received customer feedback about our feature set previewed in the Whidbey Alpha & Whidbey Beta 1 and this has guided our decision making process as to where to focus our energies to ensure a comprehensive feature set.
Below is the list of changes to System.Xml and subsidiary namespaces that have occurred between Beta 1 and Beta 2 of the .NET Framework 2.0 release.
ADDITIONS
XmlSchemaValidator
The XmlSchemaValidator class provides a push model API for W3C XML Schema validation. The primary scenario for using the XmlSchemaValidator is for validating an XML infoset in-place without having to serialize it as an XML document then reparse the document using a validating XML reader.
CHANGES
- Added overloads to the static Create() method that take XmlParserContext
- ReadValueAsXXX() methods renamed to ReadContentAsXXX(). Also reduced the number of ReadContentAsXXX() methods relative to the number of ReadValueAsXXX() methods in Whidbey beta 1.
- Added ReadElementContentAsXXX() methods which are specific to obtaining the value of element nodes
- Added methods for reading large streams of text or binary data embedded in an XML document in a streaming fashion
public virtual bool CanReadValueChunk { get; }
public virtual int ReadValueChunk (byte[] buffer, int startIndex, int count);
public virtual bool CanReadBinaryContent { get; }
public virtual int ReadContentAsBase64 (byte[] buffer, int startIndex, int count);
public virtual int ReadContentAsBinHex (byte[] buffer, int startIndex, int count);
public virtual int ReadElementContentAsBase64(byte[] buffer, int startIndex, int count);
public virtual int ReadElementContentAsBinHex(byte[] buffer, int startIndex, int count);
- Added ReadToFollowing(string localname, string namespaceURI) which moves to the next occurrence of the named element in document order.
- Added XmlSchemaValidationFlags enumeration to replace the following flags; IgnoreInlineSchema, IgnoreSchemaLocation, IgnoreValidationWarnings and IgnoreIdentityConstraints
- Added existing ValidationType enumeration to replace to replace the following flags; DtdValidate and XsdValidate
- Reduced number of WriteValue() methods
- Removed overloads of WriteStartElement and WriteStartAttribute that took an IXmlSchemaInfo parameter
- Reverted the XPathDocument to what it was in version 1.1 of the .NET Framework. It is no longer editable and no longer implements the IChangeTracking, IXmlSerializable, IXPathChangeNavigable, IXPathEditable and IRevertibleChangeTracking interfaces. The rationale for this decision is at More Information on the XPathDocument/XmlDocument Change in Whidbey beta 2
XPathNavigator and XPathEditableNavigator
- The XPathEditableNavigator has been merged into the XPathNavigator, making it an editable XML cursor model API.
- The XPathNavigator is the preferred API for exposing data as XML. This has been incorporated into the design guidelines for using XML in the .NET Framework
- The XPathNavigator returned by the CreateNavigator() method now allows one to edit the XmlDocument through the cursor model API.
- The XmlDocument now supports XML schema validation of the entire subtree or partial validation of nodes in the document using the Validate() method
- The following property added to XmlDocument
public XmlSchemaSet Schemas { get; set; }
- The following property added to XmlNode
public virtual IXmlSchemaInfo SchemaInfo { get; }
- The XslTransform class was obsoleted in Whidbey Beta 1 and replaced by the System.Xml.Query.XsltCommand class. In Beta 2, we decided to revamp the XsltCommand API in order to make migration from XslTransform simpler. This effort also resulted in the renaming of the XsltCommand class to System.Xml.Xsl.XslCompiledTransform.
- XslCompiledTransform compiles XSLT to MSIL for significantly improved performance at the cost of increased (yet still small) compile times.
- Supports the MSXML XSLT extension functions such as format-date, format-time etc.
- This class has been renamed to XmlSchemaInference
XPathExpression -
- Added static Compile() method enables one to compile an input string containing an XPath query into an XPathExpression object
REMOVALS
To reduce the cost of churn caused by the obsoletion of XslTransform this class has been removed. In its place the XsltArgumentList from v1.1 can be used
Microsoft has decided not to ship a client side XQuery implementation in .NET Framework 2.0 as our customers expect us to ship an implementation that meets the following criteria:
- Compliant with the W3C standards
- Functionally addresses key scenarios
As a core platform component in Windows, they also expect us to ship a product that meets the high bar of not breaking their applications when future updates are released. After talking to key customers and partners, we have determined it is important that we cross this high bar before shipping a full implementation of XQuery in the platform.
The best estimates tell us that ETA for XQuery to become a W3C recommendation is end of 2005 which does not fit with the .NET Framework 2.0 product release cycle.
In the meantime, we are shipping a well-defined small subset of XQuery in SQL Server 2005 to query information stored natively as XML data type. This will enable new customer scenarios in SQL Server for storing and retrieving semi-structured data.
In the NET Framework 2.0 RTM timeframe, we recommend that our customers continue to use XSLT and XPath on the client side to solve their key client side filtering and transformation scenarios. With this in mind, we have made significant improvements to our client side story including:
- Performance improvements - making the .NET Framework XSLT processor the best performing processor.
- Functional improvements - improving the usability and feature set of the existing .NET Framework processor
Note: As a result of not shipping XQuery, XML Views using mapping and XQuery to query SQL Server 2005 and the XmlAdapter to perform updates that were originally previewed in the PDC Alpha release of .NET V2.0 have also been removed. These were removed in the Beta 1 release.
Comments
- Anonymous
October 12, 2004
The comment has been removed - Anonymous
October 12, 2004
Hi Dare,
Great work as usual... however, do you know what the status of KB 317611 (support for Chameleon Schemas is?)... - Anonymous
October 13, 2004
The .NET XML classes are well-grained and powerful..but..err..a bit complex when compared to MSXML. Check out http://www.nedbatchelder.com/blog/200410.html#e20041012T161950 for a good example of what I mean - Anonymous
October 13, 2004
The XQuery part is a major ARGGGGGHHH!
And, no, supporting XQuery in SQL server is no stopgap for that; I'm interested in applying XQuery on local XML files, I'm not interested in SQL server.
Is there any hope that the existing XQuery support will be released somehow as a stand-alone technology ('unsupported' if deemed necessary)? Or do we have to use ILDasm/Ilasm on the whidbey beta 1 files to 'extract' an assembly with those classes ourselves?
I perfectly well understand your reason for not supporting a 'standard' that is not going to be a standard for some time, but retracting the existing XQuery part from whidbey beta 2 means that there isn't even an experimental XQuery implementation for the .NET framework around, anywhere. Because after Microsoft announced that they would support XQuery in Whidbey noone in their right mind would start designing their own XQuery implementation for .NET. So there are no third party implementations. - Anonymous
October 13, 2004
Luc,
If you feel you need an implementation of XQuery for the .NET Framework right away you can take a look at the Saxon.NET project hosted at http://www.x2x2x.org/x2x2x/home/
anonymouse,
The problems with chameleon schemas are fixed in Whidbey. I seem to remember us considering whether to fix this in Everett SP1 but I'm not sure if we ever did. - Anonymous
October 13, 2004
Still no easy way way to choose encodings other than UTF-16 for XmlDocument? - Anonymous
October 13, 2004
Does the lack of an XQuery implementation affect your decision on XSLT 2? (see http://blogs.msdn.com/mfussell/archive/2004/05/13/130969.aspx) - Anonymous
October 14, 2004
Dare Obasanjo shares an important update on the Beta 2 version of System.Xml 2.0. - Anonymous
October 17, 2004
.NET Framework 2.0 beta 2 で System.Xml が変わる - Anonymous
October 18, 2004
I second Luc Cluitmans comments. XQuery is key to our strategy and we need a non SqlServer approach even if unsupported and experimental. - Anonymous
October 18, 2004
While I understand the desire for XQuery on the client, are you sure you'd rather have partial support and, potentially, a client that doesn't align well to the standard deployed on every client you want to touch? That makes me jumpy. Don and Luc, I'd like to hear more about your use cases, too. Follow the link for more contact info. - Anonymous
October 21, 2004
I have to third the comments by Don and Luc. Since when has Microsoft let a little thing like standards get in its way? But seriously folks, what do different clients have to do with anything? For example, we have an n-tier app. We have our own Windows.Form thin client talking to a server using Web services. All processing is done on the server. This is especially pertinent to XQuery as that's what would be ideal to push sparse data to the client. Please, please, please. Microsoft has always been very accessible in early beta stages of products. Don't rip out XQuery now. - Anonymous
October 22, 2004
Consitency ?
You have refactored the ReadValueAsXXX() methods to be a much more appropriate ReadContentAsXXX(). Appropriate becuase the name of the method reflects the domain knowledge. Xml has content not value !
But then you've left other methods called CanReadValueChunk(), that makes no sense at all.
And why are you duplicating functionality. Whilst it may seem attractive to have all the features in one place, adding methods like ReadElementContentAsBase64() just polutes the simplicity and dilutes the consistency of the API.
Your duplicating functionality in an unneccessary and inconsistent way.
Surely it would be better to have one or two methods like ReadElementContentAsStream() and ReadElementContentAsByteArray() and allow people to use System.Convert or whatever other standard feature exists for this task.
Making a half effort to support a couple for encodings it pointless when there are guaranteed to be more, so always implement the base functionality and no more.
If your going to design an API, or an object model which you expect other people to use you may as well use it yourself otherwise its just hypocracy... not to mention bad design. - Anonymous
October 22, 2004
Steven,
I feel your pain! XQuery in the middle does make sense and would have a smaller change management foot print.
Just a thought: Suppose you installed an instance of SQL Server 2005 Express on the local app server. It wouldn't any normal database work, other than have procs that take your XML and XQuery parameters and then return results to you. Would that work?
As much as I love XQuery, I'd rather not have it in Whidbey for a number of reasons. See http://sqljunkies.com/WebLog/ktegels/archive/2004/10/13/4584.aspx - Anonymous
October 25, 2004
Over the weekend, I tried performing stylesheet transformation using the XslTransform class only to find that vbscript is not supported. Any plans to change this in the upcoming version? - Anonymous
October 25, 2004
The XslTransform class only supports the primary Common Language Runtime languages which are VB.NET, C# and JScript.NET - Anonymous
October 26, 2004
The comment has been removed - Anonymous
December 14, 2004
I was doing some catch up reading feeds I'm subscribed and I found this one item that made me feeling some sort of bitter nostalgia. It's right on MSDN TV site, a new episode where Mark Fussel explains new XML features in upcoming .NET 2.0. The episode is dated December... - Anonymous
December 22, 2004
Btw, talking with .NET developers recently (XML geeks and non-geeks) about XQuery and XSLT support in .NET 2.0 I realized that shocking fact - about 80% of devs I was talking to still have no idea XQuery support in .NET 2.0 was cut. They were listening all the road to... - Anonymous
May 01, 2005
Almost 6 months after it's been announced that Microsoft won't ship XQuery implementation in the .NET 2.0, StylusStudio (maker of the namesake XML IDE) decided to run an online petition "XQuery for all" to urge Microsoft change the mind. Well, as a marketing action it's ok, but the petition itself... - Anonymous
June 09, 2009
PingBack from http://jointpainreliefs.info/story.php?id=935