Re: Namespace: what's the correct usage?

[Martin Gudgin <marting@develop.com>]

----- Original Message -----
From: "Kohsuke KAWAGUCHI" <kohsukekawaguchi@yahoo.com>
To: "Martin Gudgin" <marting@develop.com>; <xml-dev@lists.xml.org>
Sent: Saturday, May 19, 2001 2:08 AM
Subject: Re: Namespace: what's the correct usage?


>
> Well, let me put in another way.
>
>
> You once said:
> > > martin = new best.practice.com.Person();
> > > martin.lastName = "Gudgin";
> > > martin.firstName = "Martin";
> >
> > > I don't think anyone would claim that the fields of the Person class
were
> > in
> > > the best.practice.com package. They are local to the Person class.
> >
> > Then the same logic should be applied to "martin" the instance and it
should
> > be serialized to
> >
> > <martin>
> >   <lastName> Gudgin </lastName>
> >   <firstName> Martin </firstName>
> > </martin>
> >
> > ... because nobody would claim that "martin" the instance is in the
> > best.practice.com package. It is local to that method.
> >
> > [MJG]
> > Agreed in principle, but something needs to be namespace qualified...
>
> What I asked originally was why you qualify "martin" the local variable
> while you don't qualify another local variable.
>
> I suppose you didn't show me any criteria.

[MJG]
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
the name of the local variable the class is bound to, indeed a given
instance may be bound to multiple local variable names. So I use the class
name as the localname of the top-level element.

e.g.

Person martin = new Person();
// Do some stuff with martin
// Now send him somewhere else
obj.SendMessage ( martin );


public void SendMessage ( Object o )
{
    // Use reflection to figure out what we got and serialize it as XML
}


In the above the Person instance is sometimes bound to the local name
'martin' and sometimes bound to the local name 'o'. So I use the type name
for the top level and then the field names of the Person class for the child
elements.

>
>
> As far as I know, the only rationale is to find the corresponding
> complex type declaration in XML Schema uniquely. I couldn't find any
> other reason in this discussion.

[MJG]
This namespace usage issue has nothing to do with XML Schema. Schema happens
to provide a way of describing such instances, that's all.

>
> So to me, your way is invented by XML Schema for XML Schema. That
> explains very nicely why elementFormDefault is unqualified by default.
> The only example you showed me is SOAP.

[MJG]
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. Why do you persist in implying that the namespace rec
doesn't allow unqualified local elements?

How you use namespaces is seperate from whether you use XML Schema or not. I
happen to think it's cool that Schema gives us a way of describing such
instances and that, where possible, it treats attributes and elements the
same way. But that doesn't mean I couldn't use this technique in the absence
of XML Schema. As stated earlier, SOAP has been doing it this way since Sept
99 and xML Schema was not around then ( in fact, if I remember correctly, at
that time XML Schema could not describe SOAP packets ).

>
> You sometimes mention that it is natural for data-oriented documents,
> but I know plenty of data-oriented schemas that adopt the "qualify-all"
> style.

[MJG]
I wasn't talking about 'data-oriented documents' I was talking about data
serialized as XML. I would suggest that such XML is seldom even seen by
humans. It is generated and consumed by machines.

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.

>
> There is no evidence/reason to suggest that the "unqualified local"
> style is more than just a minority. It's just that, for some reason, XML
> Schema adopts it as the default.

[MJG]
And it's used by SOAP which is a fairly popular technology, in fact I'd say
there is more XML sent as SOAP messages on any given day than there is typed
into an XML editor.

>
>
> 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
count a machine as an author. And why is this a 'small dialect'? It's just
XML. Why does using unqualified local elements lead to 'vulnerability to the
change in schema structure' and 'more typing'?

I'm perfectly happy for people who type XML into an editor to use all
qualified elements if that's what they want to do. But I predict that this
use of XML is rapidly becoming the minority. Most XML is generated and
consumed by machines, not carbon-based lifeforms ;-)

>
>
> An explanation along with this line may be more adequate.

Err, I didn't understand this last sentence?

Bottom line. Why should everyone have to use namespaces in a particular way?
I just don't get it...

Regards

Martin