Cart
[Home] [By Thread] [By Date] [Recent Entries]
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. 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" style. 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. regards, ---------------------- K.Kawaguchi E-Mail: kohsukekawaguchi@y...
|
