Re: Reading XML stream using unmanaged c++
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Tue, 21 Nov 2006 19:27:51 -0500
See below...
On Tue, 21 Nov 2006 10:17:18 GMT, Daniel James <wastebasket@xxxxxxxxxxxxxxxx> wrote:
In article news:<ihl4m21k1rsrerlesv9u3oetcs1hnugdm0@xxxxxxx>, Joseph M.****
Newcomer wrote:
Well, yes, I agree that XML nodes don't contain back-references, but every****
XML node does have exactly one immediate parent, and it's generally sorta
handy to be able to get from a node to its parent. I think that concept is
implicitly inherent in the design (if not the syntax) XML.
No, that's only because you've confused syntax with representation. There
is a unique SYNTACTIC parent to a given node, but that's no reason to
assume that the semantic model of the data structure should have the same
restriction.
You seem to be saying that DOM would be better if it didn't provide a back
pointer? Wouldn't that just make it useless for tree structures as well as for
your linear ones?
How so? You don't need a back pointer to implement tree structures. We've been building
tree structures for decades without back pointers to the parent! We taught this to
beginning students in 1967. So it is not needed.
****
****
No, I do understand the difference between syntax and semantics, but I may be
being slow to apply that understanding to XML ... almost everywhere you look
XML is described as a tool for representing trees, very few references allow
for its use for anything else ... though a few do, it's true. I'm probably
guilty of listening to the crowd who shout "XML does trees" and ignoring the
few who point out that that's not all it can do.
I'm not responsible for lack of imagination in the user community. WHat I don't want is
to be limited in what I do by that same lack of imagination. And XLink very definitely
talks about complex linked structures as an intrinsic part of XML.
****
****
You've shown that non tree-like data structures can be modelled in XML using
metadata that lie outside the syntactic elements of XML itself -- which is
fine, and I'm glad that works for you. I've never come across a project in
which XML was used for non-tree data (though I've come across a few in which
the data were deliberately distorted to be tree-like) and I don't think I
would have chosen to start with XML as a markup language if I wasn't going to
be able to take advantage of the tree structure that it supports so naturally
.. but I can see that what you're doing must work.
Sorry, XML is entirely metadata. The tags are metadata. The contents of the tags are
metadata. That's the whole point of XML: it is a massive metadata mechanism. Since
everything is metadata, adding new kinds of metadata is consistent with the XML philosophy
(if you look at the real issues in XML, it is having problem domains agree on the types of
metadata tags that will be used in their domain)
****
****
I still don't understand why you're giving DOM such a hard time, though. DOM
is a parsing tool that builds a model of the syntactic structure of an XML
document. It doesn't attach any structural significance to the contents of the
nodes -- how could it? The syntax of XML is standard, and DOM can have that
standard "programmed in", the semantics of the data in any XML document are
potentially unique to that document, and cannot be processed by any
general-purpose tool.
Because a widely-used tool should not impose artificial restrictions on the XML structure.
It definitely DOES attach structural significance, by having a completely unnecessary back
pointer that serves no meaningful purpose.
****
****
You have extended the modelling capabilities of XML by putting metadata into
node bodies. You have not extended DOM to interpret those metadata. Your
insistence that DOM is inadequate because it cannot parse the semantics of
your model therefore seems irrational -- you are asking for a magic wand.
And you can't, because it requires a unique parent pointer. This means that DOM-based
code will expect that foolish pointer to be valid, when it doesn't even need to exist at
all. If it isn't valid, because the node has multiple parents, the assumptions that DOM
uses are violated.
I don't need a magic wand. I need something that does not impose unnecessary and
irrelevant constraints on the representation. Without the back pointer, it would work
just fine for my apps, because I can, in my application, interpret my metadata without
restriction. With the back pointer, I cannot extend the representation to the full power
supported by the XML notation. So the implementation restriction violates the basic
specification that XML can be used to represent complex documents. I just gave a
complexity model that DOM can't support because it adds a gratuitous piece of information
which is inappropriate.
****
Joseph M. Newcomer [MVP]
Cheers,
Daniel.
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Follow-Ups:
- Re: Reading XML stream using unmanaged c++
- From: Daniel James
- Re: Reading XML stream using unmanaged c++
- References:
- Reading XML stream using unmanaged c++
- From: Mayur
- Re: Reading XML stream using unmanaged c++
- From: Joseph M . Newcomer
- Re: Reading XML stream using unmanaged c++
- From: David Ching
- Re: Reading XML stream using unmanaged c++
- From: Joseph M . Newcomer
- Re: Reading XML stream using unmanaged c++
- From: Daniel James
- Re: Reading XML stream using unmanaged c++
- From: Joseph M . Newcomer
- Re: Reading XML stream using unmanaged c++
- From: Daniel James
- Re: Reading XML stream using unmanaged c++
- From: Joseph M . Newcomer
- Re: Reading XML stream using unmanaged c++
- From: Daniel James
- Re: Reading XML stream using unmanaged c++
- From: Joseph M . Newcomer
- Re: Reading XML stream using unmanaged c++
- From: Daniel James
- Reading XML stream using unmanaged c++
- Prev by Date: Re: DrawCli MSDN
- Next by Date: Re: CProperty*** based application and HTML help
- Previous by thread: Re: Reading XML stream using unmanaged c++
- Next by thread: Re: Reading XML stream using unmanaged c++
- Index(es):