| Composed schemas [message #54646] |
Thu, 11 November 2004 06:33  |
Eclipse User |
|
|
|
Hi,
I've problems with composing a schema from multiple schema documents. Here
is a short example:
1) I have the schemas root.xsd, A.xsd and B.xsd. All schemas have the same
targetNamespace.
2) root.xsd includes A.xsd and B.xsd
3) A.xsd and B.xsd do not include each other
4) A.xsd uses a definition from B.xsd
So if you just parse A.xsd you will get an error message that a definition
couldn't be found. But what is the intended behaviour if you parse
root.xsd?
At the moment you also get an error message that the definition from B.xsd
couldn't be found although it is in known in root.xsd via the include of
B.xsd.
I think this is the corresponding section in the specification of W3C:
"As discussed in Missing Sub-components (§5.3), QNames in XML
representations may fail to resolve, rendering components incomplete and
unusable because of missing subcomponents. During schema construction,
implementations must retain QName values for such references, in case an
appropriately-named component becomes available to discharge the reference
by the time it is actually needed. Absent target namespace names of such
as-yet unresolved reference QNames in <include>d components must also be
converted if clause 3.2 is satisfied."
(http://www.w3.org/TR/xmlschema-1/#layer2)
You find the paragraph at the end of §4.2.1.
My question is: How do you interpret this section? Is it really correct to
get an error when reading root.xsd?
Regards
Klaas Dellschaft
|
|
|
| Re: Composed schemas [message #54673 is a reply to message #54646] |
Thu, 11 November 2004 07:28  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Klaas,
The behavior you see is the intended behavior. A schema that isn't
correct, e.g., A.xsd with missing includes/imports, cannot be made
correct by including it somewhere else.
The way I read the clause you point out is that unresolved names need to
be recorded in such a way that they can be resolved later, i.e., the
namespace URI and the local name must be recorded and available to look
up the name again later should an import or include that failed to
resolve become available.
If A.xsd uses B.xsd, it should include it. This will certainly make it
easier for any tool to edit this file in isolation.
Klaas Dellschaft wrote:
> Hi,
>
> I've problems with composing a schema from multiple schema documents.
> Here is a short example:
>
> 1) I have the schemas root.xsd, A.xsd and B.xsd. All schemas have the
> same targetNamespace.
> 2) root.xsd includes A.xsd and B.xsd
> 3) A.xsd and B.xsd do not include each other
> 4) A.xsd uses a definition from B.xsd
>
>
> So if you just parse A.xsd you will get an error message that a
> definition couldn't be found. But what is the intended behaviour if
> you parse root.xsd?
>
> At the moment you also get an error message that the definition from
> B.xsd couldn't be found although it is in known in root.xsd via the
> include of B.xsd.
>
> I think this is the corresponding section in the specification of W3C:
>
> "As discussed in Missing Sub-components (§5.3), QNames in XML
> representations may fail to resolve, rendering components incomplete
> and unusable because of missing subcomponents. During schema
> construction, implementations must retain QName values for such
> references, in case an appropriately-named component becomes available
> to discharge the reference by the time it is actually needed. Absent
> target namespace names of such as-yet unresolved reference QNames in
> <include>d components must also be converted if clause 3.2 is satisfied."
> (http://www.w3.org/TR/xmlschema-1/#layer2)
>
> You find the paragraph at the end of §4.2.1.
>
>
> My question is: How do you interpret this section? Is it really
> correct to get an error when reading root.xsd?
>
>
> Regards
> Klaas Dellschaft
>
>
|
|
|
|
|
|
| Re: Composed schemas [message #54770 is a reply to message #54742] |
Fri, 12 November 2004 07:14 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------000805090801060507060502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Klaas,
I've been thinking some more. I think clause 4 definitely does rule
that the name will be unresolved, but the section you refer to is
talking about unresolved names and can be reasonably interpreted to be
referring to precisely those names unresolved according to clause 4, and
hence can be reasonably interpreted to be amending that outcome. It
certainly does not state what conditions would make a name become
available, so an explicit statement of intent or an example would
definitely have been desirable.
Since changing the behavior of include will have the effect of making an
"invalid" set to schemas valid and will have no affect on a set of
already valid schemas, it seems reasonable to just change the behavior
in all cases, not just optionally. Open a bugzilla and I'll follow up.
Klaas Dellschaft wrote:
>>which strongly implies that for a name to resolve, it must either have the
>>same namespace as the containing schema and hence must be visible to that
>>schema element via its direct contents or via the transitive closure of
>>the
>>included contents; or it must be have a different namespace and there must
>>be an import directly in that schema element. There would seem to be no
>>point in clause 4 if one could simply lookup the name in all the available
>>names.
>>
>>
>
>I think the section you mentioned is also very important for this problem.
>But in clause 4.2.1 it only says
>
>"The actual value of the targetNamespace [attribute] of the <schema> element
>information item of the schema document containing the QName."
>
>I think just taking this sentence wouldn't lead to your conclusion that it
>has to be visible to that schema element. More important is clause 1:
>
>"That component is a member of the value of the appropriate property of the
>schema which corresponds to the schema document within which the QName
>appears, that is the appropriate case among the following must be true: ..."
>
>There it says that the resolved component (the definition in B.xsd) has to
>be known to the schema document where the QName (= the reference in A.xsd)
>appears. Here it explicitly says that it has to be contained in the schema
>of the schema *document* which is in this case A.xsd and not root.xsd (even
>if we use A.xsd in the context of root.xsd). But I think this is a
>contradiction to
|
|
|
| Re: Composed schemas [message #592425 is a reply to message #54646] |
Thu, 11 November 2004 07:28 |
| Eclipse User |
|
|
|
Klaas,
The behavior you see is the intended behavior. A schema that isn't
correct, e.g., A.xsd with missing includes/imports, cannot be made
correct by including it somewhere else.
The way I read the clause you point out is that unresolved names need to
be recorded in such a way that they can be resolved later, i.e., the
namespace URI and the local name must be recorded and available to look
up the name again later should an import or include that failed to
resolve become available.
If A.xsd uses B.xsd, it should include it. This will certainly make it
easier for any tool to edit this file in isolation.
Klaas Dellschaft wrote:
> Hi,
>
> I've problems with composing a schema from multiple schema documents.
> Here is a short example:
>
> 1) I have the schemas root.xsd, A.xsd and B.xsd. All schemas have the
> same targetNamespace.
> 2) root.xsd includes A.xsd and B.xsd
> 3) A.xsd and B.xsd do not include each other
> 4) A.xsd uses a definition from B.xsd
>
>
> So if you just parse A.xsd you will get an error message that a
> definition couldn't be found. But what is the intended behaviour if
> you parse root.xsd?
>
> At the moment you also get an error message that the definition from
> B.xsd couldn't be found although it is in known in root.xsd via the
> include of B.xsd.
>
> I think this is the corresponding section in the specification of W3C:
>
> "As discussed in Missing Sub-components (§5.3), QNames in XML
> representations may fail to resolve, rendering components incomplete
> and unusable because of missing subcomponents. During schema
> construction, implementations must retain QName values for such
> references, in case an appropriately-named component becomes available
> to discharge the reference by the time it is actually needed. Absent
> target namespace names of such as-yet unresolved reference QNames in
> <include>d components must also be converted if clause 3.2 is satisfied."
> (http://www.w3.org/TR/xmlschema-1/#layer2)
>
> You find the paragraph at the end of §4.2.1.
>
>
> My question is: How do you interpret this section? Is it really
> correct to get an error when reading root.xsd?
>
>
> Regards
> Klaas Dellschaft
>
>
|
|
|
| Re: Composed schemas [message #592437 is a reply to message #54673] |
Thu, 11 November 2004 08:49 |
| Eclipse User |
|
|
|
> The behavior you see is the intended behavior. A schema that isn't
> correct, e.g., A.xsd with missing includes/imports, cannot be made correct
> by including it somewhere else.
> The way I read the clause you point out is that unresolved names need to
> be recorded in such a way that they can be resolved later, i.e., the
> namespace URI and the local name must be recorded and available to look up
> the name again later should an import or include that failed to resolve
> become available.
But how would a scenario look like where such a definition becomes available
later? And how do I tell XSD to retry resolving such references?
From my point of view parsing A.xsd in the context of root.xsd would be such
a case. So while parsing root.xsd you have to get the list of unresolved
references from parsing A.xsd and look whether they can be resolved in the
context of root.xsd.
I think it is generally the philosophy of the W3C that included and imported
definitions become part of the including/importing schema. And in this
context the unresolved references are known. From my
> If A.xsd uses B.xsd, it should include it. This will certainly make it
> easier for any tool to edit this file in isolation.
I agree with you that this makes it easier. But the question is whether the
W3C really wants to make it easy ;-)
My dilemma is that I have to parse schemas from well known standardization
organizations (like IEEE or the IMS Global Learning Consortium) which
interpret the clause in a different way and which insist on omitting the
include in A.xsd. So I'm not in the position to insert an include statement
and in the end XSD refuses to parse these schemas.
At the moment I'm discussing with developers from IEEE whether it is an
error on their side so they have to add the include statement in their
schemas. But they told me to talk to the developers of the library which I'm
doing now ;-)
Cheers
Klaas Dellschaft
|
|
|
| Re: Composed schemas [message #592451 is a reply to message #54700] |
Thu, 11 November 2004 13:31 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------030107080300090900090909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Klaas,
Calling XSDSchema.update will make it try to resolve names again; if a
broken connection became available, it might succeed where before it didn't.
I am asking for some more opinions yet again, but I've been over this
many times already. But sometimes the answers you get change, as people
change their mind. :-(
I used to have a simpler lookup mechanism working but then I had to make
it more complex based on a careful reading of
http://www.w3.org/TR/xmlschema-1/#src-resolve
which strongly implies that for a name to resolve, it must either have
the same namespace as the containing schema and hence must be visible to
that schema *element *via its direct contents or via the transitive
closure of the included contents; or it must be have a different
namespace and there must be an import directly in that schema
*element*. There would seem to be no point in clause 4 if one could
simply lookup the name in all the available names. But I certainly see
your point about the comments in
|
|
|
| Re: Composed schemas [message #592460 is a reply to message #54727] |
Thu, 11 November 2004 19:24 |
| Eclipse User |
|
|
|
> which strongly implies that for a name to resolve, it must either have the
> same namespace as the containing schema and hence must be visible to that
> schema element via its direct contents or via the transitive closure of
> the
> included contents; or it must be have a different namespace and there must
> be an import directly in that schema element. There would seem to be no
> point in clause 4 if one could simply lookup the name in all the available
> names.
I think the section you mentioned is also very important for this problem.
But in clause 4.2.1 it only says
"The actual value of the targetNamespace [attribute] of the <schema> element
information item of the schema document containing the QName."
I think just taking this sentence wouldn't lead to your conclusion that it
has to be visible to that schema element. More important is clause 1:
"That component is a member of the value of the appropriate property of the
schema which corresponds to the schema document within which the QName
appears, that is the appropriate case among the following must be true: ..."
There it says that the resolved component (the definition in B.xsd) has to
be known to the schema document where the QName (= the reference in A.xsd)
appears. Here it explicitly says that it has to be contained in the schema
of the schema *document* which is in this case A.xsd and not root.xsd (even
if we use A.xsd in the context of root.xsd). But I think this is a
contradiction to
|
|
|
| Re: Composed schemas [message #592473 is a reply to message #54742] |
Fri, 12 November 2004 07:14 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------000805090801060507060502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Klaas,
I've been thinking some more. I think clause 4 definitely does rule
that the name will be unresolved, but the section you refer to is
talking about unresolved names and can be reasonably interpreted to be
referring to precisely those names unresolved according to clause 4, and
hence can be reasonably interpreted to be amending that outcome. It
certainly does not state what conditions would make a name become
available, so an explicit statement of intent or an example would
definitely have been desirable.
Since changing the behavior of include will have the effect of making an
"invalid" set to schemas valid and will have no affect on a set of
already valid schemas, it seems reasonable to just change the behavior
in all cases, not just optionally. Open a bugzilla and I'll follow up.
Klaas Dellschaft wrote:
>>which strongly implies that for a name to resolve, it must either have the
>>same namespace as the containing schema and hence must be visible to that
>>schema element via its direct contents or via the transitive closure of
>>the
>>included contents; or it must be have a different namespace and there must
>>be an import directly in that schema element. There would seem to be no
>>point in clause 4 if one could simply lookup the name in all the available
>>names.
>>
>>
>
>I think the section you mentioned is also very important for this problem.
>But in clause 4.2.1 it only says
>
>"The actual value of the targetNamespace [attribute] of the <schema> element
>information item of the schema document containing the QName."
>
>I think just taking this sentence wouldn't lead to your conclusion that it
>has to be visible to that schema element. More important is clause 1:
>
>"That component is a member of the value of the appropriate property of the
>schema which corresponds to the schema document within which the QName
>appears, that is the appropriate case among the following must be true: ..."
>
>There it says that the resolved component (the definition in B.xsd) has to
>be known to the schema document where the QName (= the reference in A.xsd)
>appears. Here it explicitly says that it has to be contained in the schema
>of the schema *document* which is in this case A.xsd and not root.xsd (even
>if we use A.xsd in the context of root.xsd). But I think this is a
>contradiction to
|
|
|
Powered by
FUDForum. Page generated in 0.04255 seconds
Home