OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Underwhelmed (WAS: [xml-dev] XOM micro tutorial)

[ Lists Home | Date Index | Thread Index ]

At 10:40 AM -0600 9/21/02, Aaron Skonnard wrote:

>Yes, both MSXML and the .NET implementation have supported this through
>the Inner/OuterXml properties.

Now that you mention it, I have seen that. I had filed it away at the 
back of my brain as "horrid, ugly, non-standard extensions to 
JavaScript and DOM" and promptly forgotten it once I finished working 
at the company that was using it. My one experience with this was 
that it massively confused the developers there, and led them to 
create truly awful XML systems that just weren't working. (In fact, 
that's what they brought me in to fix.) Maybe there's a good way to 
use this, but I've yet to see it, and I really don't like APIs that 
mislead developers. The right way should be obvious. The wrong way 
should be difficult to impossible.

I see a lot of programmers, many of them here on the xml-dev list, 
who are very confused about the difference between text nodes that 
contain angle brackets and  elements. Maybe MSXML and its associated 
documentation is what's confusing them.

>It actually turns out to be quite useful in certain scenarios (say,
>reading a string of XML from a DB that needs to be loaded into a

OK, I can see that, but it really does seem to confuse the layers. 
The database, presumably, is giving you an XML document. What you 
want to insert is presumably an XML element. And a string is 
something else again, that is best represented in the object model as 
a text node.

I guess what .Net is doing here is sort of a mini-parse on the 
document, extracting its root element, and inserting that. That cuts 
out a lot of middleman code if this is a common use-case. I have 
considered adding a method to my Builder class which would build a 
Document by parsing it from a String, rather than requiring the 
client to construct a StringReader first. If you are getting a lot of 
complete documents arriving in strings, this is helpful. You've gone 
a little further than that.

What's kept me from doing this so far is that the typical use-case 
people present that they've got another XML document embedded in a 
CDATA section, and they now want to parse that data. That's a bad 
design. Programmers should not be using CDATA sections for such 
purposes, and hidden nested documents no matter how encoded just 
don't make sense. I don't want to encourage this or make it easier. 
Now, if you've got an XML document in a string that's coming from 
somewhere else like a database, this is a very different story. So 
far, I just haven't heard developers asking for that.

>You must not have seen the .NET DOM implementation then (XmlNode
>hierarchy). It allows subclassing and extensibility in some very
>powerful ways.

If you're following the DOM spec though, you're stuck. The DOM does 
allow programs to create non-namespace-wellformed documents. If the 
.NET DOM implementation doesn't allow that, then it's in direct 
violation of the DOM spec.

On the other hand, by going with DOM you do gain some advantages. The 
big one is that you can layer it on top of different storage models. 
It's much more appropriate for a native XML database, for example. 
XOM does not allow you to change implementations (well, except by 
forking the source code, of course.)

>I agree with Dare. Having spent a lot of time with the Microsoft APIs, I
>didn't see anything new or outrageously compelling about the XOM design.

I don't really expect the .Net community to pay much attention to 
XOM. It's a Java API, after all. As you note, I certainly haven't 
paid much attention to .Net in the other direction. :-)

But I have worked with MSXML in the pre .Net days, and I am very 
familiar with DOM. As long as the .NET DOM implementation is a DOM 
implementation, it pulls along all of DOM's baggage: namespace aware 
and non-namespace aware methods, ugly method signatures, nodes that 
cannot be detached from the document that created them, xmlns 
attributes and namespace properties (that may even conflict with each 
other), node values that are null, integer type codes, and more. XOM 
doesn't have any of these problems. If .Net XML were to throw DOM 
out, and start from scratch, it might well come up with a solution 
that was technically equal or superior to XOM. However, the DOM 
foundation you're building on is so ugly and so fragile, I find it 
hard to believe that .Net XML is a castle instead of a house of cards.

| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS