RE: [xml-dev] Re: determining ID-ness in XML

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Gavin Thomas Nicol [mailto:gtn@rbii.com]
> Sent: Saturday, November 24, 2001 11:21 AM
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Re: determining ID-ness in XML
> 
>
> 
> That said, few application deal with that model directly, and 
> there are a  number of slants one can take. Editing applications, for 
> example, really do  need to know about whitespace, attribute ordering,
etc. etc. 
> etc. where most  data processing applications don't.

C'mon, Gavin, you WERE right 4 years ago when you argued for an XML data
model! <grin>.
If there had been a common understanding of where entities, namespace
declarations, internal subsets, and CDATA sections do or do not fit in the
representation produced by a parser, we would have avoided many frequently
asked questions, lots of hideous code, and many W3C meetings that make
participants yearn for a new career herding goats somewhere far from the
nearest computer. (Well, *I* frequently had that reaction ...)

It's a matter of "what you don't think you need to know about the XML data
model CAN hurt you." Lots of the differences between the various DOM-like
APIs come down to the data model -- are Text nodes exposed?  How do we
represent namespaces or entity references?  It whitespace visible or not?  I
can't agree that it makes sense to use a different API depending on whether
you want to see whitespace or Text nodes.

Since we don't live in a rational world, one where an application can
negotiate this with the parser/DOM/etc would be more tolerable.  OK, we
can't agree on which is the one true data model, but wouldn't you like (in a
"data" application) to say "don't show me no steenkin' CDATA sections or
whitespace nodes, and  please expose the XPath namespace model?"  Of course,
an editor would want to see these things more or less as they appear in the
XML syntax, so "document" applications would probably choose the opposite
profile.