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

RE: A multi-step approach on defining object-orientednature of

• To: "Amelia A Lewis" <amyzing@t...>
• Subject: RE: A multi-step approach on defining object-orientednature of DOM
• From: "Keith W. Boone" <keith@w...>
• Date: Wed, 21 Aug 2002 10:45:01 -0400
• Cc: <xml-dev@l...>
• Importance: Normal
• In-reply-to: <1029896844.25933.160.camel@marajen>
• Reply-to: <keith@w...>

I too am a corporate grunge.  Namespaces, how do I hate thee?  Let me count
the ways:

1.  Inheritance.  Namespace declarations in an element impose themselves
upon the children without regard to whether those children want and/or need
them.  When I put an attribute on an element, I mean for it to apply only to
that element.
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?
3.  Purpose.  What problem does it solve?  Certainly not validation of
documents which use multiple schemas.  At the time of XML Namespace
publication, XML Schemas were just barely out of the gate of the standards
development process.  So we had namespaces which would "allow" reuse of
different schemas, but no way to validate a document using more than one.
The one thing that it avoids is name collisions.  I have yet to run into
case where this is a real problem, simply because I am usually in control of
the schema which wants to reuse another.  This isn't necessarily the case
when you start using XML to transform or define schemas, but even there, it
hasn't been an issue for me yet.
4.  Extra Gunge.	It makes parsing and API representations more complex.
Sure they might not be that hard to use, but I have had to build DOM
implementation, and if I could have skipped the Namespace question, my
[working] life would have been simpler.
5.  To many names.  Elements and attributes now have local names, qualitifed
names, and expanded names.  We've all seen the discussions here about naming
resources.  Can someone tell me what the real name of an element is?
6.  Exposure.  Not only do we need to keep track of these names, but
developers of XML processing tools now have to provide access to all of the
names for a thing.  We need to be able to search not only for the expanded
name [the only necessarily unique name], but also the non-unique forms.  Now
if XML Namespaces are to avoid name collisions, why do we need the other
pieces?
7.  Hackery.  Namespaces are pure hackery built around and constrained by
the XML specification.  It is most certainly elegant hackery, but it is
hackery none-the-less.

So, what do I do?  I avoid namespaces at all when I can.

P.S. Amy, Perhaps you should give a presentation on your difficulties.
There are still opportunities to do so [XML 2002 for example].

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

• References:
  • RE: A multi-step approach on defining object-orientednature of DOM
    • From: Amelia A Lewis <amyzing@t...>

• Prev by Date: RE: namespace reprise
• Next by Date: RE: patterns vs. identifiers
• 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-orientednature of DOM
• Index(es):
  • Date
  • Thread