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

Re: Namespaces

Re:  Namespaces
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

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:


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

Compare the reworking:


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".


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.
First Name
Last Name
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.