Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

reading large... of text... in a streaming fashion

Roland Kaufmann — Wed, 13 Oct 2004 09:50:00 GMT

For the love of God! Why do you practically duplicate the Stream "interface" (and when is Stream going to be an interface and not an abstract class?) with some oddly named methods? Wouldn't it have been a much more better design to have one method Stream ValueChunk() which returns null in case it cannot return the chunk, otherwise a stream which performs the reading? Oh well, it's just one MORE wrapper to write...

re: Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

anonymouse — Wed, 13 Oct 2004 11:40:00 GMT

Hi Dare,

Great work as usual... however, do you know what the status of KB 317611 (support for Chameleon Schemas is?)...

Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

Joteke's Blog — Wed, 13 Oct 2004 13:21:00 GMT

re: Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

Sriram — Wed, 13 Oct 2004 15:42:00 GMT

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

System.XML Changes after .NET 2.0 Beta 1

Mike Taulty's Weblog — Wed, 13 Oct 2004 15:44:00 GMT

XQuery out - Arrrggghhh!

Luc Cluitmans — Wed, 13 Oct 2004 18:00:00 GMT

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.

re: Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

Dare Obasanjo — Wed, 13 Oct 2004 18:22:00 GMT

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.

re: Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

Paolo del Mundo — Wed, 13 Oct 2004 21:42:00 GMT

Still no easy way way to choose encodings other than UTF-16 for XmlDocument?

re: Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

RichB — Thu, 14 Oct 2004 00:00:00 GMT

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)

Important System.Xml 2.0 update!

Ken Brubaker — Thu, 14 Oct 2004 16:53:00 GMT

Dare Obasanjo shares an important update on the Beta 2 version of System.Xml 2.0.

System.Xml 2.0 Beta 2

Il Blog di Paolo Pialorsi — Mon, 18 Oct 2004 01:32:00 GMT

.NET Framework 2.0 beta 2 で System.Xml が変わる

青柳臣一 blog : .NET や C# がメインの blog — Mon, 18 Oct 2004 14:06:00 GMT

.NET Framework 2.0 beta 2 で System.Xml が変わる

re: Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

Don Richer — Mon, 18 Oct 2004 16:40:00 GMT

I second Luc Cluitmans comments. XQuery is key to our strategy and we need a non SqlServer approach even if unsupported and experimental.

re: Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

Kent Tegels — Tue, 19 Oct 2004 05:41:00 GMT

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.

re: Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

Steven M. Cohn — Fri, 22 Oct 2004 14:16:00 GMT

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.

re: Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

Emerson — Fri, 22 Oct 2004 19:11:00 GMT

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.

re: Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

One of these things... — Fri, 22 Oct 2004 19:16:00 GMT

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

re: Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

question — Mon, 25 Oct 2004 19:30:00 GMT

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?

re: Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

Dare Obasanjo — Mon, 25 Oct 2004 19:54:00 GMT

The XslTransform class only supports the primary Common Language Runtime languages which are VB.NET, C# and JScript.NET

re: Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

Jeremiah Johnson — Wed, 27 Oct 2004 00:55:00 GMT

I may be misunderstanding the purpose of XmlWriter.WriteValue, so I am sorry if this is way off. In the docs for XmlWriter.WriteValue( DateTime ), it says "If no parent type is available, the value is typed using the default mapping; thus, a DateTime value is mapped to the xsd:dateTime type."

According to http://www.w3.org/TR/xmlschema-2/#dateTime, the format should be in CCYY-MM-DDThh:mm:ss, but it looks like you are using CCYY-MM-DDThh:mm:ss.sssssss-HH:MM. I think that your representation may be valid as ISO 8601 goes, but as it is, there are two major problems: 1) a time zone is being pulled from outside of the DateTime which invalids it as a representation of the original DateTime and 2) that format is not supported at all in the W3C recommendation.

It is possible that I am misunderstanding the W3C recommendation (or maybe it has changed), but on the time zone, I think that WriteValue is wrong. The data going into the XML should represent the object, not the instance with a system context appended to it. An example is below.

using System;
using System.Xml;

public class Test {

public static void Main() {

XmlWriter writer = new XmlTextWriter( Console.Out );
writer.WriteStartElement( "SomeDate" );
writer.WriteValue( DateTime.Now );
writer.WriteEndElement();
writer.Close();

}

}

...produces...

<SomeDate>2004-10-26T15:45:24.5706128-06:00</SomeDate>

I think that the output should be...

<SomeDate>2004-10-26T15:45:24</SomeDate>

Thank you for your time.

- jeremiah

A letter from a dead house

Signs on the Sand — Tue, 14 Dec 2004 22:36:00 GMT

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...

XQuery in .NET story isn't over yet

Signs on the Sand — Wed, 22 Dec 2004 20:52:00 GMT

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...

XQuery in .NET 2.0 Petition - too late, guys!

Signs on the Sand — Mon, 02 May 2005 12:10:56 GMT

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...

Altova releases XQuery and XSLT 2.0 Processor with .NET Bindings

JCooney.NET — Tue, 26 Jul 2005 20:04:36 GMT

Altova releases XQuery and XSLT 2.0 Processor with .NET Bindings

JCooney.NET — Tue, 26 Jul 2005 20:10:52 GMT

Altova releases XQuery and XSLT 2.0 Processor with .NET Bindings

JCooney.NET — Tue, 26 Jul 2005 20:27:23 GMT

Dare Obasanjo s WebLog Upcoming Changes to System Xml in NET | Joint Pain Relief

Dare Obasanjo s WebLog Upcoming Changes to System Xml in NET | Joint Pain Relief — Wed, 10 Jun 2009 02:57:38 GMT

PingBack from http://jointpainreliefs.info/story.php?id=935