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

Re: Avoding a repeat of W3C XSD - was Re: Is Web 2.0


xsd readonly
* Michael Champion <michaelc.champion@g...> [2005-08-19 23:37]:
> On 8/19/05, Alan Gutierrez <alan-xml-dev@e...> 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@e...
    - http://engrm.com/blogometer/index.html
    - http://engrm.com/blogometer/rss.2.0.xml

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.