[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Namespace: what's the correct usage?
- From: "Simon St.Laurent" <email@example.com>
- To: Martin Gudgin <firstname.lastname@example.org>
- Date: Sun, 20 May 2001 09:32:53 +0000
On 20 May 2001 07:19:00 +0100, Martin Gudgin wrote:
> So what would you do with the following XML document?
> <p:book xmlns:p='urn:x1'>
> <p:title>The Hobbit</p:title>
> All the elements are namespace qualified. How do you distinguish between the
> two title elements?
The simple answer is to manage my own name conflicts, and not use
p:title twice with different meanings.
This would seem (to me) especially obvious in the context of XML Schema
where type is everything - the only reason this example works is that
p:title is just simple text. If the two titles were of genuinely
different types, there's be a much larger problem.
RELAX provides for this by permitting context-dependent content models,
but I don't think the RELAX documents encourage the practice you're
> Or take XSLT. xsl:param can appear in two places; as a child of
> stylesheet/transform or as a child of template. It *does not* mean exactly
> the same thing in both places. When it's a child of template the parameter
> is local to that template, when it is a child of stylesheet/transform the
> parameter is global. How does an XSLT processor distinguish between these
> two cases? It treats xsl:param as locally scoped and checks the parent.
Context-dependency matters in a large number of XML use cases. The
particular kind of context-dependency you are proposing (unqualified
elements belonging to their parent context) is not supported by the
Namespaces spec itself, and I think you're making enormous assumptions
about the kind of processing required to handle them without considering
the impact on exchange with other users who will not make those same
> I think my argument is that local scoping may well be in effect *anyway*.
> People are already using it without realising it. I think that making
> locally scoped elements unqualified acts as a trigger saying 'look at my
> parent! look at my parent!'.
But Namespaces in XML already defines scoping explicitly, and says "look
at my parent for xmlns declarations!" not "look at my parent for its
> I am sharing them in the markup. If the following document appeared at your
> door one night, what would you do?
> <p:person xmlns:p='urn:x2' xmlns='' >
I'd wonder why Martin Gudgin was sending me documents which seem to
demonstrate a serious lack of understanding about namespaces, even
though he appears to be three years older than I am. As a human, I'm
happy to read past namespace declarations and take guesses. Most
programs aren't nearly so forgiving.
> You'd take one look at the namespace name and local-name of the document
> element and tell it to get lost because you didn't know how to process it.
No, not necessarily. I'd look for a RDDL document at the URI specified
for p, and realize that the sender likes perverse URNs in addition to
bizarre usage of elements with no namespace URI.
If you'd dropped a RDDL document at the URI with some kind of
explanation of what you were up to, I might have used kinder words than
bizarre and perverse and maybe written some code to cope with your
> So, I'm curious, what do you do now if you see an element in no namespace?
I assume that they were created by people using vocabularies which have
no namespaces. A _lot_ of people use XML without using namespaces _at
I taught an XML Interoperability course at the Washington DC ACM last
week. I had thirty-five students. I asked how many had created XML
vocabularies - about twenty-five. (Only two are in production settings,
though.) I asked how many had used a namespace identifier on their
vocabulary - one.
People were genuinely aggravated by my suggestion that they define
namespaces even in documents which use only one vocabulary.
Seeing no namespace applied tends to remind me of that approach, and I
figure it just combined with a namespace-using approach.
> And I think the shortcut has already been taken. If anything, this makes it
> safer by not fooling people into thinking they know how to process an
> element based entirely on its local name and namespace name.
So far as I've seen, you're the only person taking this particular
shortcut. I'd be interested to hear if there's anyone else who
(independently) came to this approach.