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: Suggested guidelines for using local types. (was Re: Enlightenmentvia avoiding the T-word)

"Fuchs, Matthew" wrote:
> 
> In other words, if one follows the best practice of:
> 1) always using a targetNamespace for your schema
> 2) always making local names unqualified
> 3) writing your XSLT scripts as I've suggested
> then your scipts will be robust in the face of added local names or global
> names, all with the current generation of software and without needing
> access to the PSVI.
> 
But these quidelines need to make some reference to the difference
between unprefixed and unqualified elements (the big difference between
elements and attributes which is inexplicably unaddressed in the XML
Schema spec).

Say I have a SOAP wrapper round a qualified global element Q which in
turn contains an unqualified local element u

Now consider the following two messages:

message [1]:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
 <SOAP-ENV:Body>
  <m:Q xmlns:m="Some-URI">
   <U>DIS</U>
  </m:Q>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

message [2]:
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
 <Body>
  <m:Q xmlns:m="Some-URI">
   <U>DIS</U>
  </m:Q>
 </Body>
</Envelope>

Now are these equivalent messages? No, according to the namespace
recommendation (and XSLT) they're different - the inner element "U" is
in no namespace in the first case, and in the SOAP namespace in the
second case. What happens if I schema-validate the global element Q? I
trust, for the sake of consistency, that the second Q will be rejected,
even though it is textually identical to the first, and even though the
outer wrapper is identical in terms of, say, XSLT processsing.

The solution - as someone else pointed out, sorry I can't find the
posting - is to reset the default declaration on each global element
with unqualified locals, eg

  <m:Q xmlns:m="Some-URI" xmlns="">
   <U>DIS</U>
  </m:Q>

which can now be used safely in either context.

I know that namespace-aware processing tools should help prevent the
situation arising, but I really think that this issue should be
mentioned in any best practice discussion of local namespaces.

Francis.