OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Status of MicroXML?

On Sun, 19 Dec 2010 22:51:55 -0500, Kurt Cagle wrote:
> I don't necessarily think that removing namespaces is the answer. Reforming
> them is.

Agreed.  But I'm not sure that we're using the same language.

In my lexicon, "removing namespaces" means "returning to a single 
global namespace."

In my lexicon, "reforming namespaces" means "finding a better solution 
than Namespace in XML 1.0."

Based on this:

 I think that XQuery is one of the first languages that I've seen
> where namespace usage begins to approach that used by other programming
> language, and even there it's primarily because XQuery can be used in an
> object like context.

I don't think that that's how you're using the terms.

> In general people don't like namespaces because
> namespaces have a tendency to reflect authority, rather than library
> organization.

Do what?  If I have a collection of documents, I may have a library, 
but I don't think that that's the meaning of the term as you're using 
it.  Of course namespaces reflect authority.  Is there an example where 
they do not?

Namespaces in XML is difficult to explain because:

<elem xmlns="random string" attr="xyzzy" /> has three namespaces in 
it.  "Do which *what* now?"  "Well, elem is in the default namespace, 
which is bound to 'random string,' which is a URI.  Well, of course, it 
isn't really a URI, but it's a namespace URI, because namespace URIs 
don't have to be URIs."  "Uh.  Okay.  Right.  That's one.  So, elem, 
and this xmlns thing, and attr are ...."  You can fill in the rest of 
this, right?  Just produce incomprehensible, standard-compliant 
gibberish, and when your interlocutor grows tired of it, they join the 
"XML is stupid complex" camp and never try to cope again.

> Similarly, I think the XPath fails on this same regard. From a programmer's
> standpoint:
> */bookstore:bookSet/bookstore:book/bookstore:author*


> seems unduly redundant, and they'd be right; why can't we say
> *bookstore:/bookSet/book/author*

Insufficient.  Retains mapping, which is broken as designed.

(in my opinion, of course).

> or even
> *com.mycompany.bookstore:/bookSet/book/author

Better.  Or even /com.mycompany.bookstore:bookSet/book/author; until 
another namespace is defined, use the one defined earlier in the 
expression.  Use :gi for the global namespace.

> I worry that in the rush to "simplify" XML people are interpreting the
> problem with namespaces as being that programmers are too stupid to use


> them. I have to wonder if instead, we've created a namespace notation that
> is counterintuitive to the way that programmers handle their own namespace
> issues 

Yes.  That's part of it, at least.  You could take it as the umbrella.

> (and anyone doing OOP deals with namespaces in some fashion or
> another).

Uh.  Let's not require object orientation, please.  Me, I'm happy as a 
clam learning some of the recent functional languages.  And the 
procedural languages are generally namespaced as well.  I can't think 
of any language, in any of those three categories, that's as clumsy and 
counter-intuitive, that's as internally apparently inconsistent, as 
Namespaces in XML.

Amelia A. Lewis                    amyzing {at} talsever.com
How do you make a cat go moo?
Ask it: "Does a dog have the Buddha-nature?"

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS