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] Avoding a repeat of W3C XSD - was Re: [xml-dev] Is Web 2.0

[ Lists Home | Date Index | Thread Index ]

* Michael Champion <michaelc.champion@gmail.com> [2005-08-19 23:37]:
> On 8/19/05, Alan Gutierrez <alan-xml-dev@engrm.com> wrote:
> 
> >    This is the second time in this thread I've seen it written that
> >    Namespaces are flawed. Please point me to a disucssion or
> >    article that will illustrate the flaws in Namespaces. I'd like
> >    to read up so I can continue to follow along.
> 
> My personal favorite is http://xmlbastard.editthispage.com/discuss/msgReader$6
> [duck]

    I'm at: "DOM and Namespaces: This is terrible! Kill me now!"

    That sinking feeling. If I'd read this a two years ago, it would
    have made my path in the development of my project a lot more
    direct.
    
    I attempted to implment W3C DOM as a read-write interface to my
    page backed document object model. I'd designed the document
    structure to support and assume Namespaces.
    
    I then found all sorts of rude methods in W3C DOM, like
    setPrefix(), that implied that violating Namespaces was
    something that an application might want to do.
    
    Allowing butchery would mean a document object model that could
    make no assumptions, thus perform no optimizations. (Prefixes
    are not stored in the node, they are resolved, for example.)
    After much hand-wringing, I decided to implement a read-only W3C DOM. 

    I thought about implementing read-write with a lot of
    assertions, but I didn't want to test and raise on the great
    many opportunities exceptional conditions.

    I figured that with so many opportunities for error, existing
    W3C DOM code would invariably find one of the assertions. Maybe,
    innocently; Set the wrong prefix, then ammend the namespace
    declaration. Post-conditions, then? Feh. There was no good way
    to support legacy W3C DOM node surgery.
    
    It was a long, slow, hard slog to come to this decision. The
    specifications are so nice, formal, and recommended, I assumed
    that the confusion was through some fault of my own.

    I'm putting this out there as a user experience. I'm wondering
    how one could be made aware of these criticisms, they are just
    as valuable (and in this one case, I feel, more valuable) than
    the specification itself.

> A more temperate is 
> http://www-128.ibm.com/developerworks/xml/library/x-namcar.html
> Most discussions eventually link back to 
> http://lists.xml.org/archives/xml-dev/200204/msg00170.html

    This is amazing. Eye-opening, not sinking. Well-timed.
    
    Thank you.

--
Alan Gutierrez - alan@engrm.com
    - http://engrm.com/blogometer/index.html
    - http://engrm.com/blogometer/rss.2.0.xml




 

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

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