[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Status of MicroXML?
- From: Amelia A Lewis <amyzing@talsever.com>
- To: xml-dev@lists.xml.org
- Date: Sun, 19 Dec 2010 23:35:58 -0500
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*
Agreed.
> 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
No.
> 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.
Amy!
--
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]