[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Schema composition questions

• From: "Shlomo Yona" <S.Yona@F...>
• To: <xml-dev@l...>
• Date: Sun, 8 Jul 2007 01:05:34 -0700

Hello,

I hope that it is appropriate to post a link to a thread in xmlschema-dev, where I could not get a response (other than that of Paul Kiel, who tried kind to answer from a schema author's point of view).

I have some questions which are related to schema composition. I read the XML Schema recommendation and was not able to understand the desired correct behavior in some cases.

I hope that some of the experts here can help me by shedding some light on this. I need the perspective from an implementation of an XML processor rather than the one of a schema author (although that perspective can surely give some insights as well): I'm trying to understand how it is expected to work, not design patterns that work around incompatibility issues.

The original questions were asked here: http://lists.w3.org/Archives/Public/xmlschema-dev/2007Jul/0001.html

Some more examples for "what I mean" are listed in my response to Paul Kiel below.

Thanks for your help

Shlomo.

-----Original Message-----
From: xmlschema-dev-request@w... on behalf of Shlomo Yona
Sent: Sun 7/8/2007 10:41 AM
To: Paul Kiel; xmlschema-dev@w...
Subject: RE: schema composition questions



Hello,


[This is related to my 1st question]
>>Paul: this is certainly legal and useful. It is called "namespace
>>coercion" because you are coercing the schema B into the namespace A.  But
>>if the nesting gets more complicated it sometimes is not exactly
>>interoperable across implementations.  We ran into trouble using this some
>>time ago.

I think that I understand what happens in a trivial case such as this:
A (tns "A") includes B (no tns)

All the top level names in B are now in the namespace that A declares as its target namespace (tns "A").

What I don't understand is the case where
A (tns "A") includes B (no tns) which imports C (tns "C").
Is this a legal situation?
What is the fully qualified name of top level names from C in the composed schema document?
I would argue that the following possibilities should be considered (I am not sure that I listed all possibilities and am not sure at all which is the correct or desired behavior):
* This is illegal and the whole schema processing fails
* A include B import C fails (not all top level names in the composed B and C can be coerced into the target namespace of A) and the result is only A include B (ignoring the import of C into B)
* The composed schema is only A itself due to failure of coercing all the names in the composed B and C schema documents
* The composed schema document includes top level names in A under the target namespace "A" + top level names in B under the target namespace "A" + top level names in C under the target namespace "C".

So... what is the correct or desired behavior?



[this is related to my 2nd question]
>>Paul:  The ordering is not significant here.

Is it always the case that the order of processing xsd:import and xsd:include in a schema document is insignificant? Or are there examples where order matters?


[This is related to my 3rd question]
>>Paul: This is where interoperability can be a problem.
>>I would suggest that you keep it to one no-ns schema being
>>included into one ns schema.
>>If you have multiple levels of includes and multiple levels
>>of "coercion" then tools can interpret that differently.
>>To be frank, we ran into problems with namespace coercion
>> and decided to abandon it altogether. 

This is exactly my question. I'm asking this from an XML processor implementation point of view and not from a schema author "best practice" point of view. I want to implement the "right thing" and the correct behavior. My problem is that I do not understand from the recommendation what is exactly the correct behavior.

[This is related to my 4th question]
>>Paul: There is not a problem with circular includes per se.
>>Namespaces aside, the spec says that duplicative includes/imports
>>should be ignored.
>>So just being circular is not an error.
>>Now with namespaces, you are better off avoiding this kind of
>> behaviour because tools may interpret it differently.

Again, I want to implement the correct behavior into my XML processor. I'm not asking this as a schema author. Can you point out the proper way to handle such cases? Where in the recommendation is this issue being discussed and how is it suggested to process a set of XML schema documents that have circular dependencies in the general case?

[This is related to my 5th question]
>>Paul: not sure I understand here.
>>If it is about coercion of the namespace of the any, then I refer
>>to earlier comments.
>>If it is about what other options are available for namespace
>>declaration of any, then there are options such as "##other"
>>for specifying a different namespace, "##any" for any namespace,
>>and there are some others too.  The spec lists them.

I was probably not clear. Let me try with an example:

A (tns "A") includes B (no tns) which includes C (no tns) which imports A.
C contains: <xsd:any namespace="A"/>.
To which top level names does this wildcard refer to?
Only those listed in the A schema document?
Perhaps those listed in B too?
Perhaps those in A, B and C?

I can give other examples where this is complicated for me to understand, for example:

A (tns "A") includes AA (tns "A") and also includes B (no tns) which includes C (no tns).
C contains: <xsd:any namespace="A"/>.
But to which top level names does this wildcard refer to?
What if AA contains <xsd:any namespace="A"/>?
To which top level names does this wildcard refer to?

Of course, there are plenty more other examples to cook up which are, at least for me, similarly unclear.



I hope that you and the other experts here can help me out.

Thanks.

Shlomo.