[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: A multi-step approach on defining object-orientednatureof

• To: xml-dev@l...
• Subject: Re: A multi-step approach on defining object-orientednatureof DOM
• From: Mike Champion <mc@x...>
• Date: Wed, 21 Aug 2002 11:54:34 -0400
• In-reply-to: <200208211511.LAA07956@m...>

8/21/2002 10:57:40 AM, John Cowan <jcowan@r...> wrote:

>> 2.  Modelling.  Yeah, there's the InfoSet, then there's the DOM, and finally
>> the parsing APIs.  Can any two agree on how exactly to represent the
>> namespace data?
>
>The DOM preceded the Infoset and had to deal with legacy issues plus the
>(IMHO) will-o-the-wisp of a DOM-based XML editor.
>

That's a good point.  It's easy to complain (as I do too!) about the 
inconsistencies among the various spec's handling of namespaces.  It's
much MUCH harder to define data models and APIs that simultaneously 
meet the needs of read-only systems such as XPath/XSLT and real-world
XML authoring tools.  Not to mention the will-o-wisp of browser-based
editors in Javascript, Java, ActiveX, etc. that seemed like an obvious use case 
for the DOM at one time.

Think about the XPath "each node knows its namespace URI" model vs the
DOM / XML syntax "scoped namespace declaration nodes" model.  The
XPath model seems obviously saner and easier to use ... until you start
thinking about moving nodes around the tree.  Does the node drag its
namespace declaration along with it, or does it take on the namespace
context of its destination?  Even I (a party to the DOM Level 
2 stuff) can't think of many *practical*
situations in which moving a "p is for HTML paragraph" node into a context
where "p is for part-number" should NOT drag along the namespace declaration.
On the other hand, the "principle of least surprise" might
suggest that DOM editing follow the model of XML text editing, and
the destination context determines the namespace. That seemed like the
guiding metaphor at the time.

Also, think of the poor browser and SGML editor vendors who had the namespace spec 
inflicted on them.  It is a whole lot easier to implement namespaces
as just-a-special-attribute when you have a legacy codebase to work with,
even if the Right Thing is to rewrite from the ground up to handle the
far-reaching implications of the Namespace spec. 

I'm not sure what point I'm making here, other than maybe the various
W3C WGs who took different approaches to the namespace problem weren't
necessarily stupid, even if it looks like it in 20:20 hindsight :-)
This clearly needs to be sorted out by someone coming along behind the
Web/XML circus parade and sweeping up after the elephants.  

• Follow-Ups:
  • Re: A multi-step approach on defining object-orientednatureof DOM
    • From: Paul Prescod <paul@p...>

• References:
  • Re: A multi-step approach on defining object-orientednature of DOM
    • From: John Cowan <jcowan@r...>

• Prev by Date: RE: patterns vs. identifiers
• Next by Date: RE: XHTML 2.0: the one bright light?? (Was: linking, 80/20)
• Previous by thread: Re: A multi-step approach on defining object-orientednature of DOM
• Next by thread: Re: A multi-step approach on defining object-orientednatureof DOM
• Index(es):
  • Date
  • Thread