I think Aaron is asking about what *subset* of the .NET XML features should be ported to the Silverlight environment :-)

But to get their attention for whatever subset or superset features you think is appropriate, it would be best to be more explicit about the types of applications you would build for the Silverlight platform and why some specific XML feature would be necessary to make it work well.

Screw the subset, please support E4X! The DOM must die.

Please support SVG. That could be huge point in MSFT's favor.

@Mike,

That *WAS* my subset ;-) :D

All kidding aside, thanks for the clarification and the tip! Guess it's time to start unveiling my *SUPER TOP-SECRET* code base that will hopefully help to justify some of requested features.

Will work on that and get it posted ASAP :D

@Bill,

Careful. Mike (Champion), who's comment is just above yours, is one of the folks who developed DOM. He has sensitive feelers and I've heard rumors that he finds ways to make those who talk trash about DOM wish that trash was never talked from the general location of their DOM-trashing fingers (or mouth if the trash is spoken, though in your case fingers since it was typed ;-))

That said,

The DOM must die.

ABSOLUTELY! E4X *ROCKS*!

(Dear Mike Champion: Bill said it, not me! I was just agreeing. That doesn't count as trash talk, does it? ;-) :D )

@Dave P,

Please support SVG.

hmmm... How do I put this gently? As much as I would like it to, that ain't going to happen in my own opinion. MSFT just won *HUGE* points in developing the DLR, IronRuby, and providing .NET support as part of Silverlight. And given XAML ties directly into all of the wonderfullness of the .NET platform, and given that XAML provides all that SVG has to offer and then some (different approach to the XML syntax, but all of the capabilities++ are there), I just don't see SVG support as something we are going to see come out of the MSFT camp.

Of course, I could very easily be wrong.

That could be huge point in MSFT's favor.

True, though with the DLR, IronRuby, and support for .NET in Silverlight, I'm not so sure they are in need of winning huge points right at the moment. That will change. Always does. But with support for advanced vector graphics already, the people pounding on MSFT's door looking for handouts are not going to be pounding asking for more vector graphics support. For what I can only assume are obvious reasons, they're going to be asking for things that don't already exist

Does that mean that MSFT won't surprise us? Well, after yesterdays announcements I wouldn't be surprised by anything at this stage, but I wouldn't hold my breath, either.

I noted in https://blogs.msdn.com/mikechampion/archive/2007/05/01/reporting-for-duty-on-ws-deathstar.aspx that I figure that LINQ to XML is the only thing that might help my karma recover from DOM. I don't relish the thought of the next few hundred incarnations as a cockroach or something :-)

(But seriously folks, the DOM served a useful purpose in 1998. I wouldn't say it deserves to die, but it is ready for retirement)

@Mike,

I noticed the WS-Deathstar post the morning after you wrote it and started to write a related blog entry. At the moment, time is of the essence and as such haven't had the time to finish it off. I will get to it ASAP, but in the mean time, congratulations on the move! A *BRAVE* and *GUTSY* move, without a doubt, but I can't help but fall head over heals for your point regarding Aspect-Oriented Messaging. It's absolutely spot on!

via http://pluralsight.com/blogs/dbox/archive/2006/04/21/22282.aspx#22880 from a while back,

The WS-* group of standards tends to get a lot of trash-talk for being overly complex, and/or trying to take the better-is-better approach, but it seems to me that folks seems to overlook the fact that the reason that WS-DeathStar (see: David Heinemeier Hansson's > http://www.loudthinking.com/arc/000585.html ) is funny (to me anyway; others I'm sure feel differently) is more because they chose to Atomicize the foundation instead of building a Super-Sized, one size fits all platform specification, and less about WS-DeathStar or WS-WalkTheDog (see: http://www.oreillynet.com/xml/blog/2006/04/kurtcagleqotd_a_new_service_st.html ) resulting from such "madness."

To those who doubt and/or mock WS-*: To understand why WS-* is necessary, you must first recognize its primary purpose, and while I believe its *REALLY* easy to look at WS-* with REST-tinted glasses and see the WS-Deathstar, the problem is that the REST approach is heavily document-oriented and whether we doc-head phreaks want to admit it or not, the world of SaaS is more than *JUST* documents in a REST-oriented workflow. A service is a *service*, not a document. The end result might be a document, but to get from URI-endpoint A to URI-endpoint B many times requires a messaging infrastructure that is a bit more structured/typed than what the REST/typeless/document-oriented folks are willing to admit.

re: (But seriously folks, the DOM served a useful purpose in 1998. I wouldn't say it deserves to die, but it is ready for retirement)

Very good point! The DOM was a necessary evil, as it bridged together two completely different approaches to the world of software development (AKA document-oriented and data-oriented.) Anyone who has attempted to cross that bridge themselves understands why DOM is the way it is. It had to be to gain any level of adoption from either camps, and for that it deserves a *TON* of credit and a happy and graceful retirement.

I dunno, Mike. Having done more DOM programming in the past few months than in the past few years, I like it. One can write some incredibly ugly loops just to get the values out of option tags, but hey, once they run, they run.

I'm insensitive to pain wherever I can find working examples. OTOH, I'm learning to hate microparsing solutions for XML.

@len (and directed towards Mike),

Yet again, worser proves to be better. ;-)