- From: Shlomo Yona <S.Yona@F5.com>
- Date: Sun, 8 Jul 2007 00:41:39 -0700
- To: "Paul Kiel" <paul@xmlhelpline.com>, <xmlschema-dev@w3.org>
- Message-ID: <B546C312A37C12438A22154026CDC7E01615D04F@exchfive.olympus.f5net.com>
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.
Received on Sunday, 8 July 2007 07:41:50 UTC