[
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
>subtree).
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/ |
+----------------------------------+---------------------------------+
|
