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: Sunday, May 20, 2001 12:05 PM
Subject: Re: Namespace: what's the correct usage?


> 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 why did they? And given that Andrew is an editor on both specs, why did
he think this was reasonable per the namespace rec if so many other people
think it is not?

>
> > 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'm guessing not in my small part of the world ( which right now is mainly
schemas, protocol and Web Services )

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

Sorry, didn't mean 'maybe' as in 'you might be fine, you might not'. Meant
it in the sense of 'perhaps just a qualified top-level element would be
enough'. At the end of the day if software is written to expect a qualified
top-level element and unqualified children and that's what it gets then
everything will work as expected.

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

I didn't want to drag the community through the mire on this one. I'm just
pushing the boundaries, I guess. I want to *know* why only one approach to
namespaces is the right one...

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

I agree they are entirely different document and #2 is not valid XSLT. My
point is that in both cases the param element is locally scoped.

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

Just to make sure I understand; you want to see local-scoping out completely
whether qualified or not? Or you want to see local-scoping that uses
unqualified elements out?

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

And maybe not. I don't want to cause confusion or lead people down an
ultimately futile path. I'm looking for reasons why and why not to use a
particular approach.

Cheers

Gudge