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."
Agreed.
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.
My thinking here comes in module definitions - when I create an XQuery module, I am creating this module in its own distinct namespace:
module namespace bookstore = "com.mycompany.bookstore";
declare function bookstore:get-book($id as xs:string) as node(){...};
declare function bookstore:put-book($id as xs:string,$book as node()) as node(){...};
These are then referred to via their namespace prefix notation:
import module namespace bookstore = "com.mycompany.bookstore" at "bookstore.xq";
let $book := bookstore:get-book("My Book")
It's this use of namespace (which actually isn't a binding on the XML at all) that most programmers would see as being familiar, at least within the context of C derived languages. This is what I'm referring to as an OOP-like usage (even though in reality it usually isn't).
> 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?
Sorry - I was afraid that may be confusing. Library here refers to a library of functions (i.e., proto-classes), not a library of documents. Most OOP-trained programmers would not see "com.mycompany.bookstore" as being an authority, even though the XML community would argue that it is. They would see it as a package declaration.
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.
Yup. This gets back to the questionable decision to make namespace declarations in XML share the same space as attributes. It may have ended up being preferable at one point to create a namespace declaration type:
<#com.mycompany.bookstore#>
<bookstore>
<book>
<title>My Book</title>
<#com.mycompany.meta#>
<systemId>12359</systemId>
</#com.mycompany.meta#>
</book>
</bookstore>
</#com.mycompany.bookstore#>
or create resolved authority namespaces
<com.mycompany.bookstore:bookstore>
<book>
<title>My Book</title>
<com.mycompany.meta:systemId>12359</systemId>
</book>
</bookstore>
Creating umbrella namespaces would have helped as well:
<?ns-use com.mycompany.bookstore com.mycompany.meta?>
<bookstore>
<book>
<title>My Book</title>
<systemId>12359</systemId>
</book>
</bookstore>
(where systemId is in the com.mycompany.meta namespace)
I don't know - there are people far smarter than I on this list, but I think the central challenge is in recognizing that while namespaces are important from a domain standpoint, the current form of namespaces are creating impedence mismatches with the developers who have to work with them, especially outside of the context of XML-core tools.
> *bookstore:/bookSet/book/author*
Insufficient. Retains mapping, which is broken as designed.
(in my opinion, of course).
Agreed.
> 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.
As discussed before, XML is not OOP, and I'm not suggesting that namespaces should be utilized to identify an object class. I am saying that I think that most OOP developers tend to equate namespaces with packaging, and this is one of the reasons that there is such a disconnect between the XML and OOP communities in this regard. The XQuery module role of namespaces I think is where the correspondence is closest, but there's a fairly broad arena where namespaces have little to nothing to do with packaging. Communicating that to non-XML developers, however, is the challenge.
Kurt Cagle
