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: "Kohsuke KAWAGUCHI" <kohsukekawaguchi@yahoo.com>
To: "Martin Gudgin" <marting@develop.com>
Cc: <xml-dev@lists.xml.org>
Sent: Sunday, May 20, 2001 9:38 PM
Subject: Re: Namespace: what's the correct usage?


>
> I'm glad to know that we are not the only ones who have opinions about
> this.

Me too :-)

>
>
> > Bottom line. Why should everyone have to use namespaces in a particular
way?
> > I just don't get it...
>
> I'm just trying to say that everyone should avoid using unqualified
> local elements. It doesn't mean we have to use it in only one way.

Seems to me that there are three broad ways of using namespaces;

1.    Everything is unqualified ( not using namespaces at all )
2.    Everything is qualified
3.    A mixture

You are advocating 2. I'm advocating 3.

>
>
>
> > Actually, I provided that example because I thought you may be happier
with
> > it. In reality I use the class name for the top-level element. Why?
Because
> > typically I'm serializing an instance of a class and I probably don't
know
>
> OK, then take a look at another example of yours. I think you agree to
> unqualify title, genre, and familyName.
>
> <p:book xmlns:p='urn:x1'>
>   <title>The Hobbit</title>
>   <genre>Fantasy</genre>
>   <p:author>
>     <title>Dr</title>
>     <familyName>Tolkien</familyName>
>   </p:author>
> </p:book>
>
> But I guess you would object to unqualify <author> element. But why?
> "author" is a field of an instance of the book type, just like title and
> genre do.

Actually this example is pretty much what I do in practice ( outside of
SOAP ). I tend to qualify 'significant' things, I *might* go so far as to
say I'd tend to qualify elements of complex type and leave elements of
simple type unqualified.

>
>
> If you don't object to unqualify <author> element. Then the root element
> is the only element in your instance that is qualified. Then what is
> the reason to qualify <book>? Why not unqualify all?

Because if nothing is qualified I don't know whether what I got is really
what I expect or just something that looks the same by accident.

>
> Technically, your statement that the "unqualified-local" doctrine is
> suitable for "data serialized as XML" is wrong.

Why? I can see no *technical* reason why using locally scoped unqualified
elements is wrong...

>
>
>
> > No, this was not invented by XML Schema, unqualified elements are
allowed by
> > the namespaces rec just as unqualified attributes are allowed by the
> > namespaces rec.
>
> Of course it is "allowed".  But it's just that nobody imagined that such
> an interpretation is possible.

I think many people did imagine just such an interpretation otherwise you
and I would not be having this discussion

>
>
> > Again, I reiterate, it's not that the qualify-all approach is wrong,
it's
> > that I don't see it as the only approach.
>
> I know. I can't state without some hesitation that it is THE only one
> approach. But I believe the unqualified-local doctrine is wrong.

OK. I don't see unqualified locals as a doctrine or as something to beleive
in or not. It seems like a legal, valid approach to me...

>
>
> > And it's used by SOAP which is a fairly popular technology, in fact I'd
say
>
> That's why I really want to know if there is any other spec that uses
> the same doctrine.  So far, nothing is mentioned by anyone.
>
> I checked XML-RPC but it doesn't use XML namespaces at all.

XML-RPC predates the namespace REC, I think.

>
>
> > > If so, the innocent authors should be warned not to be trapped to such
a
> > > small dialect just because he/she wants to use XML Schema. And in fact
> > > there are many practical reasons (vulnerability to the change of the
> > > schema structure, more typing, etc.) that he/she should avoid it.
> >
> > [MJG]
> > What authors? There are no (few?) authors for SOAP messages, unless you
>
> I meant "the innocent schema authors" who are just beginning to learn
> XML Schema.
>
>
> > And why is this a 'small dialect'?
>
> Because virtually every known schema (except SOAP) uses the "qualify-all"
> doctrine.
>
>
> > Why does using unqualified local elements lead to 'vulnerability to the
> > change in schema structure' and 'more typing'?
>
> "It is vulnerable to the change in a schema file" because instance
> documents have to be changed if you change one of your local declaration
> to a global one so that it can be shared.
>
> "It needs more typing" because you can't use the default namespace
> declaration.
>
> I think these are objective facts.

I'll grant you that changing the schema requires changing the instance but
I'm not sure what your point is... If the schema is changed and the instance
document doesn't need to change *then* I would be worried...

I'll also grant that having to type 4 extra characters for each element it
'more typing'. I'm going out to be stock in keyboard companies ;-) ;-)

>
>
> > > An explanation along with this line may be more adequate.
> > Err, I didn't understand this last sentence?
>
> Sorry. I meant that an explanation along with this line is probably more
> adequate for my "XML Schema: DOs and DON'Ts", as the reason of why one
> should avoid unqualified local elements.

OK, I get it now :-)

Cheers

Gudge