Re: Namespace: what's the correct usage?

["Simon St.Laurent" <simonstl@simonstl.com>]

	8c0@greyarea><990296865.1337.0.camel@localhost.localdomain><00e601c0e0b4$7ec
	 21e80$0500a8c0@greyarea><990298368.1339.1.camel@localhost.localdomain>
	<00ff01c0e0f4$c3dbd520$0500a8c0@greyarea>
	<990351207.1339.2.camel@localhost.localdomain> 
	<000801c0e13b$4c89c030$0500a8c0@greyarea>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 20 May 2001 11:05:13 +0000
Message-Id: <990356714.1339.4.camel@localhost.localdomain>
Mime-Version: 1.0

On 20 May 2001 15:43:54 +0100, Martin Gudgin wrote:
> > 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
> > unsupported assumptions.
> 
> Then why did one of the editors of the Namespace rec use this approach in
> SOAP?

Given Microsoft's long history of screwing up Namespaces in XML... oh,
never mind.  Looking at the spec more closely, I'm deeply disappointed
to report that SOAP's creators appear to have gone that route.

> But software is not yet at a stage of being able to read, understand and
> generate more software from RDDL.

No, but humans can.  And humans are still a critical part of the
equation for a lot of this.

> > I assume that they were created by people using vocabularies which have
> > no namespaces.  A _lot_ of people use XML without using namespaces _at
> > all_.
> 
> Right! And again, if you were a piece of software you'd stop right there.
> But if you'd seen a namespace qualified parent then maybe you'd be fine?

Maybe isn't good enough for interchange in my universe, sorry. Maybe
it's monastic, but interchange is my criteria for useful/dangerous.

That's an assumption I wouldn't have built into my processing, and it's
not an assumption built into the Namespaces in XML specification.  I'd
assume I was looking at two different vocabularies, not a single
vocabularies which relied on parent-element scoping.

> > Seeing no namespace applied tends to remind me of that approach, and I
> > figure it just combined with a namespace-using approach.
> 
> I think that namespaces are crucial to XML. The make XML extensible rather
> than arbitrary. I always use namespaces sometimes I qualify everything,
> sometimes I don't. It depends on what I'm doing.

I'm not sure that most people find namespaces that crucial.  I keep
thinking that they must, since most W3C activity uses them, and then I
go out and give presentations, and find that most people aren't using
them unless they're knocked over the head with them.

And then conversations like this one pop up, and it looks like
namespaces are even less thoroughly understood (by the community as a
whole) than we thought.

> Well, the SOAP world in general uses this style and I don't really see that
> much difference between;
> 
> <xsl:transform xmlns:xsl='http://www.w3.org/2001/XMLSchema' >
> 
>   <xsl:param name='foo' />
> 
>   <xsl:template match='bar' >
>     <xsl:param name='baz' />
>   </xsl:template>
> 
> </xsl:transform>
> 
> 
> <xsl:transform xmlns:xsl='http://www.w3.org/2001/XMLSchema' >
> 
>   <param name='foo' />
> 
>   <xsl:template match='bar' >
>     <param name='baz' />
>   </xsl:template>
> 
> </xsl:transform>
> 
> Both use local-scoping. Are you happier with the all-qualified approach with
> local-scoping? Or do you think local-scoping is completely out?

To me, those are entirely different documents, and I don't think #2 would go through an XSLT processor.

In general, I'd prefer to see your style of local-scoping entirely out.  Unfortunately, I think it'll end up in the bag of namespace tricks (like QNames in attribute values) which are understood in some contexts but not in others, complicating generic XML processing immeasurably.

But hey, maybe that's what some people want.