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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Namespace: what's the correct usage?

----- Original Message -----
From: "Simon St.Laurent" <simonstl@simonstl.com>
To: "Martin Gudgin" <marting@develop.com>
Cc: <xml-dev@lists.xml.org>
Sent: Saturday, May 19, 2001 7:52 PM
Subject: Re: Namespace: what's the correct usage?

> On 19 May 2001 23:38:56 +0100, Martin Gudgin wrote:
> > > > But attributes are declared in the scope of their owner element. Why
> > > > child elements? This is the crux of the question I think.
> > >
> > > You certainly can write processors which behave this way, but there's
> > > nothing _in the markup_ which indicates that the namespace scope for
> > > child elements behaves that way.
> >
> > [MJG]
> > What about the qualified parent element? It is in the markup and would
> > perfectly well as a namespace scope for its attributes. I'm just
> > that in my case to the child elements.
> But that's going beyond the scoping rules presented in Namespaces in
> XML.  The logic that understands that scoping has to take place at the
> application level, and the labels coming strictly out of the parse are
> downright misleading given anything resembling a conservative reading of
> Namespaces in XML.

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?

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.

> > [MJG]
> > Agreed. But local scoping is useful in programming languages and I
> > anticipate that it will be ( is? ) useful in XML documents even when not
> > dealing with class serialization.
> Then I suggest that you create a namespace which indicates that local
> scoping of this kind is in effect, rather than relying on an assumption
> about elements which have no namespace which may not hold true in pretty
> much every XML processing environment I've encountered.

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!'.

> > > Unfortunately, I think the way you're going about using namespaces
> > > a lot of potentially unfounded assumptions about how the document will
> > > be processed.  In an environment you completely control, that's fine,
> > > but if your documents ever leak out to the rest of the world, you may
> > > well find that no one else shares your assumptions and that therefore
> > > the document is interpreted quite differently.
> >
> > [MJG]
> > I think whichever way you use namespaces you are making assumptions
> > the people who will see and process your XML. People use local scoping
> > programming languages because it was recognised that putting everything
> > global variables was a bad idea. I suspect that over time a similar
> > observation may apply to XML.
> Sure - we're always making assumptions.  But if you're designing for
> interchange, it's usually wise to be as absolutely explicit as possible
> about the assumptions you're making, and to share them _in the markup_.

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='' >

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.

> By relying on a null value without explaining the meaning of that null
> value, you're potentially misleading anyone else who has to deal with
> your XML document in any context other than the one you create.

So, I'm curious, what do you do now if you see an element in no namespace?

> From my perspective, you're taking a very dangerous shortcut, one which
> is more dangerous to other people than to yourself.  It might be smart
> to create a namespace URI - like http://develop.com/ns/localscoping -
> and put a RDDL document there explaining what you're doing.  That might
> get you out of a number of the concerns expressed here _and_ provide a
> means for other people to explain that they're also taking your
> shortcut.

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.