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>; <xml-dev@lists.xml.org>
Sent: Thursday, May 17, 2001 5:43 PM
Subject: Namespace: what's the correct usage?

> > They are local to the person
> > class. The person class *is* in the namespace but the fields are not.
> It seems to me that you are mixing up types and instances.

I don't think so. See below...

> It would certainly make sense if you say your Person class as a type
> resides in the namespace "http://best.practice.com" but the type of the
> is String so it should be in a different namespace.

That is exactly the position I took.

> In other words, the following type definition would make sense.
> <complexType name="Person" xmlns:java="...">
>   <sequence>
>     <element name="firstName" type="java:String"/>
>     <element name="lastName" type="java:String"/>
>   </sequence>
> </complexType>

Given that the types I used were in the schema namespace I effectively had
the above, albeit with a different namespace URI for the string type. The
person type and the string type were still in different namespaces.

> But in the instance below, you use "person","firstName", and "lastName" as
> an instance name, not as a type.

Yes, because types describe instances and I was following you initial

> <foo:person xmlns:foo="http://best.practice.com">
>   <lastName> KAWAGUCHI </lastName>
>   <firstName> Kohsuke </firstName>
> </foo:person>
> So why you qualify "person" as an instance name while you don't qualify
> "firstName" and "lastName" as instance names.

Perhaps you would have prefered;

<p:martin xmlns:p='http://best.practice.com' >

along with the following schema;

<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'
           targetNamespace='http://best.practice.com' >
  <xs:element name='martin' type='this:Person' />
  <xs:complexType name='Person' >
      <xs:element type='xs:string' name='lastName' />
      <xs:element type='xs:string' name='firstName' />

which would be analogous to the following Java class definition;

package best.practice.com;

public class Person
    String lastName;
    String firstName;

and some client side code;

best.practice.com.Person martin;

martin = new best.practice.com.Person();
martin.lastName = "Gudgin";
martin.firstName = "Martin";

The above code is legal java ( assuming it's actually inside some method
somewhere :-) )

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. Another
class in the same package could have the same field names and there would be
no confusion on the part of the Java compiler/programmer/VM

So, the most natural mapping, to me, is to take the same approach when
serializing the class as XML...

> Correct me if I'm wrong. As far as I know, when the concept of this
> unqualified local element is introduced (back in 1999,Nov), the rationale
> is that you can find the corresponding declaration only by seeing the
> tag name. So I believe XML Schema invents your way of using XML
> namespaces.

I don't think so. It was possible to do this *way* before XML Schema came
along. In fact, you've been able to do this since the namespaces rec was
done. For example, SOAP has always done it this way and has been around
since Sept '99.

> SVG, SMIL, MathML ...  There are plenty of schemas that use XML
> namespaces in my way. Would you show me some specs that use XML
> namespaces as you suggest?

No argument, XSLT is another example that makes all elements global. I was
*not* saying your way was wrong. I *was* saying that the unqualified
children approach is equally valid, especially when using XML to serialize
programmatic types.

> > If, and it's a *very* big if, I came across familyName in isolation then
> > you're right, I wouldn't know what to do with it. I would need to walk
> > up the tree until I found a namespace qualified element that I
> > What's the big deal? This happens with attributes all the time.
> Technically it's not a big deal, but it's still an extra work. Because
> you don't need to look up descendants if you qualify elements from the
> beginning.
> And sorry I couldn't get the sentence "This happens with attributes all
> the time."

My point about attributes is this; you seem to have no problem with locally
scoped attributes. That is you advocate having attributes that are
unqualified. The only way to correctly interpret an unqualified attribute is
to look at the element that owns that attribute. What is so bad about taking
the same approach to child elements?

Example, you advocate the style below for attributes;

<p:Person xmlns:p='urn:foo' firstName='Martin' lastName='Gudgin' />

yet say the following is bad;

<p:Person xmlns:p='urn:foo' >

Why? Seems inconsistent to me...


Martin Gudgin