Lists Home |
Date Index |
* Michael Champion <email@example.com> [2005-08-19 23:37]:
> On 8/19/05, Alan Gutierrez <firstname.lastname@example.org> 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
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
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
> Most discussions eventually link back to
This is amazing. Eye-opening, not sinking. Well-timed.
Alan Gutierrez - email@example.com