[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Namespace: what's the correct usage?
- From: Kohsuke KAWAGUCHI <firstname.lastname@example.org>
- To: Martin Gudgin <email@example.com>, firstname.lastname@example.org
- Date: Fri, 18 May 2001 18:08:42 -0700
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
> > 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...
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.
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.
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.
You sometimes mention that it is natural for data-oriented documents,
but I know plenty of data-oriented schemas that adopt the "qualify-all"
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.
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.
An explanation along with this line may be more adequate.