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

Re: Namespaces

• To: xml-dev <xml-dev@l...>
• Subject: Re: Namespaces
• From: Arjun Ray <aray@n...>
• Date: Wed, 16 Oct 2002 18:56:45 +0000
• In-reply-to: <B82ZJH1V7264QKOID00GFNIRMJILKLJ.3dad88e0@MChamp>
• References: <gvvqqu8mvvnsmogtr82kc6ac5m54b93gp3@4...> <B82ZJH1V7264QKOID00GFNIRMJILKLJ.3dad88e0@MChamp>

Mike Champion <mc@x...> wrote:

| a) what specific ways do namespaces bite people who understand them and 
| use software that supports them properly?

It's not so much an issue of "do" as "will".  Namespaces will bite hard
when it comes to associating more than one significant name to the same
data value.  (Why did it have to be xlink:href **VERSUS** html:src, for
instance?)  It's an implicit assumption of namespaces that only one name
ever applies to any value - that factoring into *disjoint* "namespaced"
components is the only meaningful way to look at the content of compound
documents.

This is counterfactual enough to be ludicrous.  It is normal for data to
have information value in multiple taxonomies simultaneously, which is why
all markup is fundamentally annotative, not ontologically declarative, and
why all names used in markup are instrumental, not immanently universal or
whatever.  (After a year of enduring relentless and insensate babbling on
"globally unique names" and G*d knows what else in the way of amateur
philosophizing on the now defunct w3c-xml-sig, I really don't have the
stomach for any more.) 

One common workaround is introducing extra element structure, carefully
crafted to avoid invited complications such as extraneous white space (as
pretty printers could innocently create), and indeterminate opacity (why
do you ignore only the *tagging* of other namespaces?), such as the first
example ("book review") here:

 http://www.xml.com/pub/a/1999/01/namespaces.html

Note how stuff like 

 <h:td><xdc:author>Simon St. Laurent</xdc:author></h:td>

really needs to be on one line with the tags cheek by jowl (Why? Because
two syntactically distinct elements are being used to annotate exactly the
same *value*).  We also really shouldn't get into why the <h:>'s all have
the <xdc:>s within them (does this meet *any* understanding of content as
analytic?).

Compare the reworking:

 http://lists.xml.org/archives/xml-dev/200002/msg00609.html

and note that colonified names are utterly and completely unnecessary.

I'll concede that, to people immersed in namespace theology, this is not
obvious.  Attribute-based processing is still undiscovered - oops, that
should be unreinvented - in the XML world. 

As usual, the only way we learn is the hard way.  Give it a couple of
years, at least.

| b) What should one do to avoid being bitten, given that they are 
| pervasive? 

Drop the mindset.  What makes you *think* namespaces will solve the
problems you face?

| c) How would one do it differently in 20:20 hindsight? 

Not rush into premature "standardization".

• References:
  • Re: Namespaces
    • From: Arjun Ray <aray@n...>
  • Re: Namespaces
    • From: Mike Champion <mc@x...>

• Prev by Date: Re: The XML 1.1 Candidate Recommendation is published
• Next by Date: Re: The XML 1.1 Candidate Recommendation is published
• Previous by thread: Re: Namespaces
• Next by thread: Re: Namespaces
• Index(es):
  • Date
  • Thread