|
| Re: Composed schemas [message #54673 is a reply to message #54646] |
Thu, 11 November 2004 12: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 #54727 is a reply to message #54700] |
Thu, 11 November 2004 18:31 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
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 #54770 is a reply to message #54742] |
Fri, 12 November 2004 12: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 12:28 |
 Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
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
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: Composed schemas [message #592451 is a reply to message #54700] |
Thu, 11 November 2004 18:31 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: Composed schemas [message #592473 is a reply to message #54742] |
Fri, 12 November 2004 12:14 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.04036 seconds
] 
Search
Help
Register
Login
Home
