[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Namespace: what's the correct usage?
- From: Martin Gudgin <firstname.lastname@example.org>
- To: Kohsuke KAWAGUCHI <email@example.com>, firstname.lastname@example.org
- Date: Fri, 18 May 2001 09:03:45 +0100
----- Original Message -----
From: "Kohsuke KAWAGUCHI" <email@example.com>
To: "Martin Gudgin" <firstname.lastname@example.org>; <email@example.com>
Sent: Thursday, May 17, 2001 11:00 PM
Subject: Re: Namespace: what's the correct usage?
> 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
> 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
<lastName> Gudgin </lastName>
<firstName> Martin </firstName>
... because nobody would claim that "martin" the instance is in the
best.practice.com package. It is local to that method.
Agreed in principle, but something needs to be namespace qualified...
> For example, SOAP has always done it this way and has been around
> since Sept '99.
Hmm. OK. Actually this is my first time to read the spec of SOAP, but I
found plenty of examples in the spec.
I'd appreciate if you would show me one or two more examples.
More SOAP examples?
> My point about attributes is this; you seem to have no problem with
> scoped attributes. That is you advocate having attributes that are
> unqualified. The only way to correctly interpret an unqualified attribute
> to look at the element that owns that attribute. What is so bad about
Because unqualified attributes reside in the small namespace that its
owner element creates. It's called "the per-element-type partitions."
Any unqualified element, on the other hand, resides in the no-namespace.
(I don't know the correct terminology.)
I think this is a significant difference.
And I don't think it is a significant difference. That part of the spec is
non-normative, I take it to be saying 'here is *one* way to think about
namespaces'. Looking at an unqualified element or an unqualified attribute
through an API like SAX or DOM will give you the same namespace URI. XML
Schema has to a certain degree leveled the playing field between elements
and attributes. This namespace usage is a case in point and default and
fixed values for elements are another example.
I just don't see what the big deal is. Markup languages like XSLT and others
you mention qualify all elements, that's fine. Data serialization may take a
different approach. I think this is also perfectly OK. I don't think there
is any 'correct usage' that applies to all scenarios.