Home » Archived » XML Schema Definition (XSD) » Problem Including schemas
| Problem Including schemas [message #38076] |
Mon, 08 March 2004 12:34  |
 Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
Ed,
A question that I had over a year ago has come up again and I rummaged
through my correspondence with the Eclipse XSD newsgroups/forums and found
the email below. It's a question concerning nested schemae. I have
included the email at the bottom of this mail.
I took a look at the XML Schema spec and I think that the relevant part is
at http://www.w3.org/TR/xmlschema-1/#compound-schema. I took a look at the
"Professional XML Schemas" published by Wrox, and on page 274 in Chapter
8, there is a bolded out sentence that says "If the schema we include
borrows from other schemas, we only have to reference the topmost schema
for it to pull in other schemas it references".
Thanks,
Hayden Marchant
From 26 Jan 2003:
Hayden,
Sorry for the long delay answering forum questions...
In the example below, B.xsd must have an include of C.xsd in order to be
valid. Including B.xsd in A.xsd will not help to resolve the ref to "id"
in
B.xsd. According to the spec (in my reading of it), for a QName to resolve,
there must be an explicit import/include/redefine directly in the .xsd
file;
the "id" element simply isn't visible in B.xsd when the schema for B.xsd is
being (transitively) processed. Perhaps other processors are more tolerant
of
this error, perhaps even resolving the identifier via indirect
includes/imports, but XSD is strict in this regard. And since the ref to
"id"
doesn't resolve, a placeholder element is provided by XSD instead and that
placeholder doesn't have a type.
Adding the include to B.xsd is not a hack, it's required.
Hayden Marchant wrote:
> I have encountered a problem with the references schema resolving - below
> I explain the scenario:
>
> I have 3 xsds - A.xsd, B.xsd, and C.xsd.
>
> Here are snippets of my schemas:
>
> A.xsd:
>
> <xs:include schemaLocation="B.xsd"/>
> <xs:include schemaLocation="C.xsd"/>
> <xs:element name="car">
> <xs:complexType>
> <xs:sequence>
> <xs:element ref="service"/>
> <xs:element ref="model"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> B.xsd
>
> <xs:element name="service>
> <complexTYpe>
> <sequence>
> <element ref="id"/>
> </sequence>
> </complexType>
> </xs:element>
>
> C.xsd
>
> <xs:element name="id>....
>
> <xs:element name="model...
>
> Now, when validating A.xsd, then the whole group of schemas is valid, even
> though the element reference 'id' that is referenced in B, is defined in
> C, and there in no include/import of C. this works since in A.xsd we are
> including both B and C, so as a whole, we have no problems.
>
> However, when I parse A.xsd with eclipse xsd, and I look at the
> XSDElementDeclaration for 'id' in schema B, when I call
> XSDElementDeclaration.getTypeDefinition() it returns null, and not the
> XSDTypeDefintion for id (whether it be a complex type of simple type).
>
> At the moment I have hacked my B.xsd to have the include statement.
>
> Other parsers can cope with this problem, and XML Spy lets my open my
> A.xsd is does not complain (but does complain when I open B.xsd)
>
> I hope that my explanation is clear.
--
Ed Merks
|
|
|
| Re: Problem Including schemas [message #38109 is a reply to message #38076] |
Mon, 08 March 2004 13:13  |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Hayden,
Clause 4 of http://www.w3.org/TR/xmlschema-1/#src-resolve seems pretty clear
that for a QName to resolve within a schema document, the document containing it
must have an import of that QName's namespace. I don't have access to the book
you mention, but the line you quote only seems to be saying something about how
the schema is assembled and what names are available in that schema for
validating XML instances as described in
http://www.w3.org/TR/xmlschema-1/#cvc-resolve-instance. Just because a name is
available for validating an instance, doesn't mean it's visible in a particular
schema document without an import.
Hayden Marchant wrote:
> Ed,
>
> A question that I had over a year ago has come up again and I rummaged
> through my correspondence with the Eclipse XSD newsgroups/forums and found
> the email below. It's a question concerning nested schemae. I have
> included the email at the bottom of this mail.
>
> I took a look at the XML Schema spec and I think that the relevant part is
> at http://www.w3.org/TR/xmlschema-1/#compound-schema. I took a look at the
> "Professional XML Schemas" published by Wrox, and on page 274 in Chapter
> 8, there is a bolded out sentence that says "If the schema we include
> borrows from other schemas, we only have to reference the topmost schema
> for it to pull in other schemas it references".
>
> Thanks,
> Hayden Marchant
>
> From 26 Jan 2003:
>
> Hayden,
>
> Sorry for the long delay answering forum questions...
>
> In the example below, B.xsd must have an include of C.xsd in order to be
> valid. Including B.xsd in A.xsd will not help to resolve the ref to "id"
> in
> B.xsd. According to the spec (in my reading of it), for a QName to resolve,
> there must be an explicit import/include/redefine directly in the .xsd
> file;
> the "id" element simply isn't visible in B.xsd when the schema for B.xsd is
> being (transitively) processed. Perhaps other processors are more tolerant
> of
> this error, perhaps even resolving the identifier via indirect
> includes/imports, but XSD is strict in this regard. And since the ref to
> "id"
> doesn't resolve, a placeholder element is provided by XSD instead and that
> placeholder doesn't have a type.
>
> Adding the include to B.xsd is not a hack, it's required.
>
> Hayden Marchant wrote:
>
> > I have encountered a problem with the references schema resolving - below
> > I explain the scenario:
> >
> > I have 3 xsds - A.xsd, B.xsd, and C.xsd.
> >
> > Here are snippets of my schemas:
> >
> > A.xsd:
> >
> > <xs:include schemaLocation="B.xsd"/>
> > <xs:include schemaLocation="C.xsd"/>
> > <xs:element name="car">
> > <xs:complexType>
> > <xs:sequence>
> > <xs:element ref="service"/>
> > <xs:element ref="model"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:element>
> >
> > B.xsd
> >
> > <xs:element name="service>
> > <complexTYpe>
> > <sequence>
> > <element ref="id"/>
> > </sequence>
> > </complexType>
> > </xs:element>
> >
> > C.xsd
> >
> > <xs:element name="id>....
> >
> > <xs:element name="model...
> >
> > Now, when validating A.xsd, then the whole group of schemas is valid, even
> > though the element reference 'id' that is referenced in B, is defined in
> > C, and there in no include/import of C. this works since in A.xsd we are
> > including both B and C, so as a whole, we have no problems.
> >
> > However, when I parse A.xsd with eclipse xsd, and I look at the
> > XSDElementDeclaration for 'id' in schema B, when I call
> > XSDElementDeclaration.getTypeDefinition() it returns null, and not the
> > XSDTypeDefintion for id (whether it be a complex type of simple type).
> >
> > At the moment I have hacked my B.xsd to have the include statement.
> >
> > Other parsers can cope with this problem, and XML Spy lets my open my
> > A.xsd is does not complain (but does complain when I open B.xsd)
> >
> > I hope that my explanation is clear.
>
> --
> Ed Merks
|
|
|
| Re: Problem Including schemas [message #38142 is a reply to message #38076] |
Mon, 08 March 2004 13:50 |
Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
Just another note. I looked at the xml-schemadev mailing list and found a
connected thread:
http://lists.w3.org/Archives/Public/xmlschema-dev/2002Oct/00 23.html. Seems
like it says that A includes B includes C, means A includes B and C.
Hayden Marchant wrote:
> Ed,
> A question that I had over a year ago has come up again and I rummaged
> through my correspondence with the Eclipse XSD newsgroups/forums and found
> the email below. It's a question concerning nested schemae. I have
> included the email at the bottom of this mail.
> I took a look at the XML Schema spec and I think that the relevant part is
> at http://www.w3.org/TR/xmlschema-1/#compound-schema. I took a look at the
> "Professional XML Schemas" published by Wrox, and on page 274 in Chapter
> 8, there is a bolded out sentence that says "If the schema we include
> borrows from other schemas, we only have to reference the topmost schema
> for it to pull in other schemas it references".
> Thanks,
> Hayden Marchant
> From 26 Jan 2003:
> Hayden,
> Sorry for the long delay answering forum questions...
> In the example below, B.xsd must have an include of C.xsd in order to be
> valid. Including B.xsd in A.xsd will not help to resolve the ref to "id"
> in
> B.xsd. According to the spec (in my reading of it), for a QName to resolve,
> there must be an explicit import/include/redefine directly in the .xsd
> file;
> the "id" element simply isn't visible in B.xsd when the schema for B.xsd is
> being (transitively) processed. Perhaps other processors are more tolerant
> of
> this error, perhaps even resolving the identifier via indirect
> includes/imports, but XSD is strict in this regard. And since the ref to
> "id"
> doesn't resolve, a placeholder element is provided by XSD instead and that
> placeholder doesn't have a type.
> Adding the include to B.xsd is not a hack, it's required.
> Hayden Marchant wrote:
> > I have encountered a problem with the references schema resolving - below
> > I explain the scenario:
> >
> > I have 3 xsds - A.xsd, B.xsd, and C.xsd.
> >
> > Here are snippets of my schemas:
> >
> > A.xsd:
> >
> > <xs:include schemaLocation="B.xsd"/>
> > <xs:include schemaLocation="C.xsd"/>
> > <xs:element name="car">
> > <xs:complexType>
> > <xs:sequence>
> > <xs:element ref="service"/>
> > <xs:element ref="model"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:element>
> >
> > B.xsd
> >
> > <xs:element name="service>
> > <complexTYpe>
> > <sequence>
> > <element ref="id"/>
> > </sequence>
> > </complexType>
> > </xs:element>
> >
> > C.xsd
> >
> > <xs:element name="id>....
> >
> > <xs:element name="model...
> >
> > Now, when validating A.xsd, then the whole group of schemas is valid, even
> > though the element reference 'id' that is referenced in B, is defined in
> > C, and there in no include/import of C. this works since in A.xsd we are
> > including both B and C, so as a whole, we have no problems.
> >
> > However, when I parse A.xsd with eclipse xsd, and I look at the
> > XSDElementDeclaration for 'id' in schema B, when I call
> > XSDElementDeclaration.getTypeDefinition() it returns null, and not the
> > XSDTypeDefintion for id (whether it be a complex type of simple type).
> >
> > At the moment I have hacked my B.xsd to have the include statement.
> >
> > Other parsers can cope with this problem, and XML Spy lets my open my
> > A.xsd is does not complain (but does complain when I open B.xsd)
> >
> > I hope that my explanation is clear.
> --
> Ed Merks
|
|
|
| Re: Problem Including schemas [message #38208 is a reply to message #38109] |
Mon, 08 March 2004 15:42 |
Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
Ed,
Clause 4 is referring to elements of different namespaces - i.e. it's
talking about <import> and not <include>. It seems that there is some
difference in the spec.
Am I right?
Ed Merks wrote:
> Hayden,
> Clause 4 of http://www.w3.org/TR/xmlschema-1/#src-resolve seems pretty clear
> that for a QName to resolve within a schema document, the document
containing it
> must have an import of that QName's namespace. I don't have access to the
book
> you mention, but the line you quote only seems to be saying something about
how
> the schema is assembled and what names are available in that schema for
> validating XML instances as described in
> http://www.w3.org/TR/xmlschema-1/#cvc-resolve-instance. Just because a name
is
> available for validating an instance, doesn't mean it's visible in a
particular
> schema document without an import.
> Hayden Marchant wrote:
> > Ed,
> >
> > A question that I had over a year ago has come up again and I rummaged
> > through my correspondence with the Eclipse XSD newsgroups/forums and found
> > the email below. It's a question concerning nested schemae. I have
> > included the email at the bottom of this mail.
> >
> > I took a look at the XML Schema spec and I think that the relevant part is
> > at http://www.w3.org/TR/xmlschema-1/#compound-schema. I took a look at the
> > "Professional XML Schemas" published by Wrox, and on page 274 in Chapter
> > 8, there is a bolded out sentence that says "If the schema we include
> > borrows from other schemas, we only have to reference the topmost schema
> > for it to pull in other schemas it references".
> >
> > Thanks,
> > Hayden Marchant
> >
> > From 26 Jan 2003:
> >
> > Hayden,
> >
> > Sorry for the long delay answering forum questions...
> >
> > In the example below, B.xsd must have an include of C.xsd in order to be
> > valid. Including B.xsd in A.xsd will not help to resolve the ref to "id"
> > in
> > B.xsd. According to the spec (in my reading of it), for a QName to resolve,
> > there must be an explicit import/include/redefine directly in the .xsd
> > file;
> > the "id" element simply isn't visible in B.xsd when the schema for B.xsd is
> > being (transitively) processed. Perhaps other processors are more tolerant
> > of
> > this error, perhaps even resolving the identifier via indirect
> > includes/imports, but XSD is strict in this regard. And since the ref to
> > "id"
> > doesn't resolve, a placeholder element is provided by XSD instead and that
> > placeholder doesn't have a type.
> >
> > Adding the include to B.xsd is not a hack, it's required.
> >
> > Hayden Marchant wrote:
> >
> > > I have encountered a problem with the references schema resolving - below
> > > I explain the scenario:
> > >
> > > I have 3 xsds - A.xsd, B.xsd, and C.xsd.
> > >
> > > Here are snippets of my schemas:
> > >
> > > A.xsd:
> > >
> > > <xs:include schemaLocation="B.xsd"/>
> > > <xs:include schemaLocation="C.xsd"/>
> > > <xs:element name="car">
> > > <xs:complexType>
> > > <xs:sequence>
> > > <xs:element ref="service"/>
> > > <xs:element ref="model"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:element>
> > >
> > > B.xsd
> > >
> > > <xs:element name="service>
> > > <complexTYpe>
> > > <sequence>
> > > <element ref="id"/>
> > > </sequence>
> > > </complexType>
> > > </xs:element>
> > >
> > > C.xsd
> > >
> > > <xs:element name="id>....
> > >
> > > <xs:element name="model...
> > >
> > > Now, when validating A.xsd, then the whole group of schemas is valid,
even
> > > though the element reference 'id' that is referenced in B, is defined in
> > > C, and there in no include/import of C. this works since in A.xsd we are
> > > including both B and C, so as a whole, we have no problems.
> > >
> > > However, when I parse A.xsd with eclipse xsd, and I look at the
> > > XSDElementDeclaration for 'id' in schema B, when I call
> > > XSDElementDeclaration.getTypeDefinition() it returns null, and not the
> > > XSDTypeDefintion for id (whether it be a complex type of simple type).
> > >
> > > At the moment I have hacked my B.xsd to have the include statement.
> > >
> > > Other parsers can cope with this problem, and XML Spy lets my open my
> > > A.xsd is does not complain (but does complain when I open B.xsd)
> > >
> > > I hope that my explanation is clear.
> >
> > --
> > Ed Merks
|
|
|
| Re: Problem Including schemas [message #38305 is a reply to message #38208] |
Mon, 08 March 2004 16:27 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Hayden,
I'm not sure where you are going with this? Given a document with a QName in it,
that QName either uses then namespace of the document or some other one; in the
former case, the document must define something with than name or must include
(directly or recursively) something with that name, in the later case, it must have
an import of that namespace. The document b.xsd doesn't define nor include
something that defines "id", so it is invalid (and it won't suddenly become valid
by virtue of being included in a context that defines "id").
Hayden Marchant wrote:
> Ed,
>
> Clause 4 is referring to elements of different namespaces - i.e. it's
> talking about <import> and not <include>. It seems that there is some
> difference in the spec.
>
> Am I right?
>
> Ed Merks wrote:
>
> > Hayden,
>
> > Clause 4 of http://www.w3.org/TR/xmlschema-1/#src-resolve seems pretty clear
> > that for a QName to resolve within a schema document, the document
> containing it
> > must have an import of that QName's namespace. I don't have access to the
> book
> > you mention, but the line you quote only seems to be saying something about
> how
> > the schema is assembled and what names are available in that schema for
> > validating XML instances as described in
> > http://www.w3.org/TR/xmlschema-1/#cvc-resolve-instance. Just because a name
> is
> > available for validating an instance, doesn't mean it's visible in a
> particular
> > schema document without an import.
>
> > Hayden Marchant wrote:
>
> > > Ed,
> > >
> > > A question that I had over a year ago has come up again and I rummaged
> > > through my correspondence with the Eclipse XSD newsgroups/forums and found
> > > the email below. It's a question concerning nested schemae. I have
> > > included the email at the bottom of this mail.
> > >
> > > I took a look at the XML Schema spec and I think that the relevant part is
> > > at http://www.w3.org/TR/xmlschema-1/#compound-schema. I took a look at the
> > > "Professional XML Schemas" published by Wrox, and on page 274 in Chapter
> > > 8, there is a bolded out sentence that says "If the schema we include
> > > borrows from other schemas, we only have to reference the topmost schema
> > > for it to pull in other schemas it references".
> > >
> > > Thanks,
> > > Hayden Marchant
> > >
> > > From 26 Jan 2003:
> > >
> > > Hayden,
> > >
> > > Sorry for the long delay answering forum questions...
> > >
> > > In the example below, B.xsd must have an include of C.xsd in order to be
> > > valid. Including B.xsd in A.xsd will not help to resolve the ref to "id"
> > > in
> > > B.xsd. According to the spec (in my reading of it), for a QName to resolve,
> > > there must be an explicit import/include/redefine directly in the .xsd
> > > file;
> > > the "id" element simply isn't visible in B.xsd when the schema for B.xsd is
> > > being (transitively) processed. Perhaps other processors are more tolerant
> > > of
> > > this error, perhaps even resolving the identifier via indirect
> > > includes/imports, but XSD is strict in this regard. And since the ref to
> > > "id"
> > > doesn't resolve, a placeholder element is provided by XSD instead and that
> > > placeholder doesn't have a type.
> > >
> > > Adding the include to B.xsd is not a hack, it's required.
> > >
> > > Hayden Marchant wrote:
> > >
> > > > I have encountered a problem with the references schema resolving - below
> > > > I explain the scenario:
> > > >
> > > > I have 3 xsds - A.xsd, B.xsd, and C.xsd.
> > > >
> > > > Here are snippets of my schemas:
> > > >
> > > > A.xsd:
> > > >
> > > > <xs:include schemaLocation="B.xsd"/>
> > > > <xs:include schemaLocation="C.xsd"/>
> > > > <xs:element name="car">
> > > > <xs:complexType>
> > > > <xs:sequence>
> > > > <xs:element ref="service"/>
> > > > <xs:element ref="model"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:element>
> > > >
> > > > B.xsd
> > > >
> > > > <xs:element name="service>
> > > > <complexTYpe>
> > > > <sequence>
> > > > <element ref="id"/>
> > > > </sequence>
> > > > </complexType>
> > > > </xs:element>
> > > >
> > > > C.xsd
> > > >
> > > > <xs:element name="id>....
> > > >
> > > > <xs:element name="model...
> > > >
> > > > Now, when validating A.xsd, then the whole group of schemas is valid,
> even
> > > > though the element reference 'id' that is referenced in B, is defined in
> > > > C, and there in no include/import of C. this works since in A.xsd we are
> > > > including both B and C, so as a whole, we have no problems.
> > > >
> > > > However, when I parse A.xsd with eclipse xsd, and I look at the
> > > > XSDElementDeclaration for 'id' in schema B, when I call
> > > > XSDElementDeclaration.getTypeDefinition() it returns null, and not the
> > > > XSDTypeDefintion for id (whether it be a complex type of simple type).
> > > >
> > > > At the moment I have hacked my B.xsd to have the include statement.
> > > >
> > > > Other parsers can cope with this problem, and XML Spy lets my open my
> > > > A.xsd is does not complain (but does complain when I open B.xsd)
> > > >
> > > > I hope that my explanation is clear.
> > >
> > > --
> > > Ed Merks
|
|
|
| Re: Problem Including schemas [message #38506 is a reply to message #38305] |
Tue, 09 March 2004 16:28 |
Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
Sorry, my mistake. I was getting 2 different scenarios mixed up. we really
need to get XSD authors to use Eclipse instead of XML Spy - there are too
many illegal XSD's out there :)
Thanks,
Hayden
Ed Merks wrote:
> Hayden,
> I'm not sure where you are going with this? Given a document with a QName
in it,
> that QName either uses then namespace of the document or some other one; in
the
> former case, the document must define something with than name or must
include
> (directly or recursively) something with that name, in the later case, it
must have
> an import of that namespace. The document b.xsd doesn't define nor include
> something that defines "id", so it is invalid (and it won't suddenly become
valid
> by virtue of being included in a context that defines "id").
> Hayden Marchant wrote:
> > Ed,
> >
> > Clause 4 is referring to elements of different namespaces - i.e. it's
> > talking about <import> and not <include>. It seems that there is some
> > difference in the spec.
> >
> > Am I right?
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > Clause 4 of http://www.w3.org/TR/xmlschema-1/#src-resolve seems pretty
clear
> > > that for a QName to resolve within a schema document, the document
> > containing it
> > > must have an import of that QName's namespace. I don't have access to
the
> > book
> > > you mention, but the line you quote only seems to be saying something
about
> > how
> > > the schema is assembled and what names are available in that schema for
> > > validating XML instances as described in
> > > http://www.w3.org/TR/xmlschema-1/#cvc-resolve-instance. Just because a
name
> > is
> > > available for validating an instance, doesn't mean it's visible in a
> > particular
> > > schema document without an import.
> >
> > > Hayden Marchant wrote:
> >
> > > > Ed,
> > > >
> > > > A question that I had over a year ago has come up again and I rummaged
> > > > through my correspondence with the Eclipse XSD newsgroups/forums and
found
> > > > the email below. It's a question concerning nested schemae. I have
> > > > included the email at the bottom of this mail.
> > > >
> > > > I took a look at the XML Schema spec and I think that the relevant
part is
> > > > at http://www.w3.org/TR/xmlschema-1/#compound-schema. I took a look at
the
> > > > "Professional XML Schemas" published by Wrox, and on page 274 in
Chapter
> > > > 8, there is a bolded out sentence that says "If the schema we include
> > > > borrows from other schemas, we only have to reference the topmost
schema
> > > > for it to pull in other schemas it references".
> > > >
> > > > Thanks,
> > > > Hayden Marchant
> > > >
> > > > From 26 Jan 2003:
> > > >
> > > > Hayden,
> > > >
> > > > Sorry for the long delay answering forum questions...
> > > >
> > > > In the example below, B.xsd must have an include of C.xsd in order to
be
> > > > valid. Including B.xsd in A.xsd will not help to resolve the ref to
"id"
> > > > in
> > > > B.xsd. According to the spec (in my reading of it), for a QName to
resolve,
> > > > there must be an explicit import/include/redefine directly in the .xsd
> > > > file;
> > > > the "id" element simply isn't visible in B.xsd when the schema for
B.xsd is
> > > > being (transitively) processed. Perhaps other processors are more
tolerant
> > > > of
> > > > this error, perhaps even resolving the identifier via indirect
> > > > includes/imports, but XSD is strict in this regard. And since the ref
to
> > > > "id"
> > > > doesn't resolve, a placeholder element is provided by XSD instead and
that
> > > > placeholder doesn't have a type.
> > > >
> > > > Adding the include to B.xsd is not a hack, it's required.
> > > >
> > > > Hayden Marchant wrote:
> > > >
> > > > > I have encountered a problem with the references schema resolving -
below
> > > > > I explain the scenario:
> > > > >
> > > > > I have 3 xsds - A.xsd, B.xsd, and C.xsd.
> > > > >
> > > > > Here are snippets of my schemas:
> > > > >
> > > > > A.xsd:
> > > > >
> > > > > <xs:include schemaLocation="B.xsd"/>
> > > > > <xs:include schemaLocation="C.xsd"/>
> > > > > <xs:element name="car">
> > > > > <xs:complexType>
> > > > > <xs:sequence>
> > > > > <xs:element ref="service"/>
> > > > > <xs:element ref="model"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > > </xs:element>
> > > > >
> > > > > B.xsd
> > > > >
> > > > > <xs:element name="service>
> > > > > <complexTYpe>
> > > > > <sequence>
> > > > > <element ref="id"/>
> > > > > </sequence>
> > > > > </complexType>
> > > > > </xs:element>
> > > > >
> > > > > C.xsd
> > > > >
> > > > > <xs:element name="id>....
> > > > >
> > > > > <xs:element name="model...
> > > > >
> > > > > Now, when validating A.xsd, then the whole group of schemas is valid,
> > even
> > > > > though the element reference 'id' that is referenced in B, is
defined in
> > > > > C, and there in no include/import of C. this works since in A.xsd we
are
> > > > > including both B and C, so as a whole, we have no problems.
> > > > >
> > > > > However, when I parse A.xsd with eclipse xsd, and I look at the
> > > > > XSDElementDeclaration for 'id' in schema B, when I call
> > > > > XSDElementDeclaration.getTypeDefinition() it returns null, and not
the
> > > > > XSDTypeDefintion for id (whether it be a complex type of simple
type).
> > > > >
> > > > > At the moment I have hacked my B.xsd to have the include statement.
> > > > >
> > > > > Other parsers can cope with this problem, and XML Spy lets my open my
> > > > > A.xsd is does not complain (but does complain when I open B.xsd)
> > > > >
> > > > > I hope that my explanation is clear.
> > > >
> > > > --
> > > > Ed Merks
|
|
|
| Re: Problem Including schemas [message #583867 is a reply to message #38076] |
Mon, 08 March 2004 13:13 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Hayden,
Clause 4 of http://www.w3.org/TR/xmlschema-1/#src-resolve seems pretty clear
that for a QName to resolve within a schema document, the document containing it
must have an import of that QName's namespace. I don't have access to the book
you mention, but the line you quote only seems to be saying something about how
the schema is assembled and what names are available in that schema for
validating XML instances as described in
http://www.w3.org/TR/xmlschema-1/#cvc-resolve-instance Just because a name is
available for validating an instance, doesn't mean it's visible in a particular
schema document without an import.
Hayden Marchant wrote:
> Ed,
>
> A question that I had over a year ago has come up again and I rummaged
> through my correspondence with the Eclipse XSD newsgroups/forums and found
> the email below. It's a question concerning nested schemae. I have
> included the email at the bottom of this mail.
>
> I took a look at the XML Schema spec and I think that the relevant part is
> at http://www.w3.org/TR/xmlschema-1/#compound-schema I took a look at the
> "Professional XML Schemas" published by Wrox, and on page 274 in Chapter
> 8, there is a bolded out sentence that says "If the schema we include
> borrows from other schemas, we only have to reference the topmost schema
> for it to pull in other schemas it references".
>
> Thanks,
> Hayden Marchant
>
> From 26 Jan 2003:
>
> Hayden,
>
> Sorry for the long delay answering forum questions...
>
> In the example below, B.xsd must have an include of C.xsd in order to be
> valid. Including B.xsd in A.xsd will not help to resolve the ref to "id"
> in
> B.xsd. According to the spec (in my reading of it), for a QName to resolve,
> there must be an explicit import/include/redefine directly in the .xsd
> file;
> the "id" element simply isn't visible in B.xsd when the schema for B.xsd is
> being (transitively) processed. Perhaps other processors are more tolerant
> of
> this error, perhaps even resolving the identifier via indirect
> includes/imports, but XSD is strict in this regard. And since the ref to
> "id"
> doesn't resolve, a placeholder element is provided by XSD instead and that
> placeholder doesn't have a type.
>
> Adding the include to B.xsd is not a hack, it's required.
>
> Hayden Marchant wrote:
>
> > I have encountered a problem with the references schema resolving - below
> > I explain the scenario:
> >
> > I have 3 xsds - A.xsd, B.xsd, and C.xsd.
> >
> > Here are snippets of my schemas:
> >
> > A.xsd:
> >
> > <xs:include schemaLocation="B.xsd"/>
> > <xs:include schemaLocation="C.xsd"/>
> > <xs:element name="car">
> > <xs:complexType>
> > <xs:sequence>
> > <xs:element ref="service"/>
> > <xs:element ref="model"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:element>
> >
> > B.xsd
> >
> > <xs:element name="service>
> > <complexTYpe>
> > <sequence>
> > <element ref="id"/>
> > </sequence>
> > </complexType>
> > </xs:element>
> >
> > C.xsd
> >
> > <xs:element name="id>....
> >
> > <xs:element name="model...
> >
> > Now, when validating A.xsd, then the whole group of schemas is valid, even
> > though the element reference 'id' that is referenced in B, is defined in
> > C, and there in no include/import of C. this works since in A.xsd we are
> > including both B and C, so as a whole, we have no problems.
> >
> > However, when I parse A.xsd with eclipse xsd, and I look at the
> > XSDElementDeclaration for 'id' in schema B, when I call
> > XSDElementDeclaration.getTypeDefinition() it returns null, and not the
> > XSDTypeDefintion for id (whether it be a complex type of simple type).
> >
> > At the moment I have hacked my B.xsd to have the include statement.
> >
> > Other parsers can cope with this problem, and XML Spy lets my open my
> > A.xsd is does not complain (but does complain when I open B.xsd)
> >
> > I hope that my explanation is clear.
>
> --
> Ed Merks
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem Including schemas [message #583878 is a reply to message #38076] |
Mon, 08 March 2004 13:50 |
Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
Just another note. I looked at the xml-schemadev mailing list and found a
connected thread:
http://lists.w3.org/Archives/Public/xmlschema-dev/2002Oct/00 23.html Seems
like it says that A includes B includes C, means A includes B and C.
Hayden Marchant wrote:
> Ed,
> A question that I had over a year ago has come up again and I rummaged
> through my correspondence with the Eclipse XSD newsgroups/forums and found
> the email below. It's a question concerning nested schemae. I have
> included the email at the bottom of this mail.
> I took a look at the XML Schema spec and I think that the relevant part is
> at http://www.w3.org/TR/xmlschema-1/#compound-schema I took a look at the
> "Professional XML Schemas" published by Wrox, and on page 274 in Chapter
> 8, there is a bolded out sentence that says "If the schema we include
> borrows from other schemas, we only have to reference the topmost schema
> for it to pull in other schemas it references".
> Thanks,
> Hayden Marchant
> From 26 Jan 2003:
> Hayden,
> Sorry for the long delay answering forum questions...
> In the example below, B.xsd must have an include of C.xsd in order to be
> valid. Including B.xsd in A.xsd will not help to resolve the ref to "id"
> in
> B.xsd. According to the spec (in my reading of it), for a QName to resolve,
> there must be an explicit import/include/redefine directly in the .xsd
> file;
> the "id" element simply isn't visible in B.xsd when the schema for B.xsd is
> being (transitively) processed. Perhaps other processors are more tolerant
> of
> this error, perhaps even resolving the identifier via indirect
> includes/imports, but XSD is strict in this regard. And since the ref to
> "id"
> doesn't resolve, a placeholder element is provided by XSD instead and that
> placeholder doesn't have a type.
> Adding the include to B.xsd is not a hack, it's required.
> Hayden Marchant wrote:
> > I have encountered a problem with the references schema resolving - below
> > I explain the scenario:
> >
> > I have 3 xsds - A.xsd, B.xsd, and C.xsd.
> >
> > Here are snippets of my schemas:
> >
> > A.xsd:
> >
> > <xs:include schemaLocation="B.xsd"/>
> > <xs:include schemaLocation="C.xsd"/>
> > <xs:element name="car">
> > <xs:complexType>
> > <xs:sequence>
> > <xs:element ref="service"/>
> > <xs:element ref="model"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:element>
> >
> > B.xsd
> >
> > <xs:element name="service>
> > <complexTYpe>
> > <sequence>
> > <element ref="id"/>
> > </sequence>
> > </complexType>
> > </xs:element>
> >
> > C.xsd
> >
> > <xs:element name="id>....
> >
> > <xs:element name="model...
> >
> > Now, when validating A.xsd, then the whole group of schemas is valid, even
> > though the element reference 'id' that is referenced in B, is defined in
> > C, and there in no include/import of C. this works since in A.xsd we are
> > including both B and C, so as a whole, we have no problems.
> >
> > However, when I parse A.xsd with eclipse xsd, and I look at the
> > XSDElementDeclaration for 'id' in schema B, when I call
> > XSDElementDeclaration.getTypeDefinition() it returns null, and not the
> > XSDTypeDefintion for id (whether it be a complex type of simple type).
> >
> > At the moment I have hacked my B.xsd to have the include statement.
> >
> > Other parsers can cope with this problem, and XML Spy lets my open my
> > A.xsd is does not complain (but does complain when I open B.xsd)
> >
> > I hope that my explanation is clear.
> --
> Ed Merks
|
|
|
| Re: Problem Including schemas [message #583904 is a reply to message #38109] |
Mon, 08 March 2004 15:42 |
Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
Ed,
Clause 4 is referring to elements of different namespaces - i.e. it's
talking about <import> and not <include>. It seems that there is some
difference in the spec.
Am I right?
Ed Merks wrote:
> Hayden,
> Clause 4 of http://www.w3.org/TR/xmlschema-1/#src-resolve seems pretty clear
> that for a QName to resolve within a schema document, the document
containing it
> must have an import of that QName's namespace. I don't have access to the
book
> you mention, but the line you quote only seems to be saying something about
how
> the schema is assembled and what names are available in that schema for
> validating XML instances as described in
> http://www.w3.org/TR/xmlschema-1/#cvc-resolve-instance Just because a name
is
> available for validating an instance, doesn't mean it's visible in a
particular
> schema document without an import.
> Hayden Marchant wrote:
> > Ed,
> >
> > A question that I had over a year ago has come up again and I rummaged
> > through my correspondence with the Eclipse XSD newsgroups/forums and found
> > the email below. It's a question concerning nested schemae. I have
> > included the email at the bottom of this mail.
> >
> > I took a look at the XML Schema spec and I think that the relevant part is
> > at http://www.w3.org/TR/xmlschema-1/#compound-schema I took a look at the
> > "Professional XML Schemas" published by Wrox, and on page 274 in Chapter
> > 8, there is a bolded out sentence that says "If the schema we include
> > borrows from other schemas, we only have to reference the topmost schema
> > for it to pull in other schemas it references".
> >
> > Thanks,
> > Hayden Marchant
> >
> > From 26 Jan 2003:
> >
> > Hayden,
> >
> > Sorry for the long delay answering forum questions...
> >
> > In the example below, B.xsd must have an include of C.xsd in order to be
> > valid. Including B.xsd in A.xsd will not help to resolve the ref to "id"
> > in
> > B.xsd. According to the spec (in my reading of it), for a QName to resolve,
> > there must be an explicit import/include/redefine directly in the .xsd
> > file;
> > the "id" element simply isn't visible in B.xsd when the schema for B.xsd is
> > being (transitively) processed. Perhaps other processors are more tolerant
> > of
> > this error, perhaps even resolving the identifier via indirect
> > includes/imports, but XSD is strict in this regard. And since the ref to
> > "id"
> > doesn't resolve, a placeholder element is provided by XSD instead and that
> > placeholder doesn't have a type.
> >
> > Adding the include to B.xsd is not a hack, it's required.
> >
> > Hayden Marchant wrote:
> >
> > > I have encountered a problem with the references schema resolving - below
> > > I explain the scenario:
> > >
> > > I have 3 xsds - A.xsd, B.xsd, and C.xsd.
> > >
> > > Here are snippets of my schemas:
> > >
> > > A.xsd:
> > >
> > > <xs:include schemaLocation="B.xsd"/>
> > > <xs:include schemaLocation="C.xsd"/>
> > > <xs:element name="car">
> > > <xs:complexType>
> > > <xs:sequence>
> > > <xs:element ref="service"/>
> > > <xs:element ref="model"/>
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:element>
> > >
> > > B.xsd
> > >
> > > <xs:element name="service>
> > > <complexTYpe>
> > > <sequence>
> > > <element ref="id"/>
> > > </sequence>
> > > </complexType>
> > > </xs:element>
> > >
> > > C.xsd
> > >
> > > <xs:element name="id>....
> > >
> > > <xs:element name="model...
> > >
> > > Now, when validating A.xsd, then the whole group of schemas is valid,
even
> > > though the element reference 'id' that is referenced in B, is defined in
> > > C, and there in no include/import of C. this works since in A.xsd we are
> > > including both B and C, so as a whole, we have no problems.
> > >
> > > However, when I parse A.xsd with eclipse xsd, and I look at the
> > > XSDElementDeclaration for 'id' in schema B, when I call
> > > XSDElementDeclaration.getTypeDefinition() it returns null, and not the
> > > XSDTypeDefintion for id (whether it be a complex type of simple type).
> > >
> > > At the moment I have hacked my B.xsd to have the include statement.
> > >
> > > Other parsers can cope with this problem, and XML Spy lets my open my
> > > A.xsd is does not complain (but does complain when I open B.xsd)
> > >
> > > I hope that my explanation is clear.
> >
> > --
> > Ed Merks
|
|
|
| Re: Problem Including schemas [message #583958 is a reply to message #38208] |
Mon, 08 March 2004 16:27 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Hayden,
I'm not sure where you are going with this? Given a document with a QName in it,
that QName either uses then namespace of the document or some other one; in the
former case, the document must define something with than name or must include
(directly or recursively) something with that name, in the later case, it must have
an import of that namespace. The document b.xsd doesn't define nor include
something that defines "id", so it is invalid (and it won't suddenly become valid
by virtue of being included in a context that defines "id").
Hayden Marchant wrote:
> Ed,
>
> Clause 4 is referring to elements of different namespaces - i.e. it's
> talking about <import> and not <include>. It seems that there is some
> difference in the spec.
>
> Am I right?
>
> Ed Merks wrote:
>
> > Hayden,
>
> > Clause 4 of http://www.w3.org/TR/xmlschema-1/#src-resolve seems pretty clear
> > that for a QName to resolve within a schema document, the document
> containing it
> > must have an import of that QName's namespace. I don't have access to the
> book
> > you mention, but the line you quote only seems to be saying something about
> how
> > the schema is assembled and what names are available in that schema for
> > validating XML instances as described in
> > http://www.w3.org/TR/xmlschema-1/#cvc-resolve-instance Just because a name
> is
> > available for validating an instance, doesn't mean it's visible in a
> particular
> > schema document without an import.
>
> > Hayden Marchant wrote:
>
> > > Ed,
> > >
> > > A question that I had over a year ago has come up again and I rummaged
> > > through my correspondence with the Eclipse XSD newsgroups/forums and found
> > > the email below. It's a question concerning nested schemae. I have
> > > included the email at the bottom of this mail.
> > >
> > > I took a look at the XML Schema spec and I think that the relevant part is
> > > at http://www.w3.org/TR/xmlschema-1/#compound-schema I took a look at the
> > > "Professional XML Schemas" published by Wrox, and on page 274 in Chapter
> > > 8, there is a bolded out sentence that says "If the schema we include
> > > borrows from other schemas, we only have to reference the topmost schema
> > > for it to pull in other schemas it references".
> > >
> > > Thanks,
> > > Hayden Marchant
> > >
> > > From 26 Jan 2003:
> > >
> > > Hayden,
> > >
> > > Sorry for the long delay answering forum questions...
> > >
> > > In the example below, B.xsd must have an include of C.xsd in order to be
> > > valid. Including B.xsd in A.xsd will not help to resolve the ref to "id"
> > > in
> > > B.xsd. According to the spec (in my reading of it), for a QName to resolve,
> > > there must be an explicit import/include/redefine directly in the .xsd
> > > file;
> > > the "id" element simply isn't visible in B.xsd when the schema for B.xsd is
> > > being (transitively) processed. Perhaps other processors are more tolerant
> > > of
> > > this error, perhaps even resolving the identifier via indirect
> > > includes/imports, but XSD is strict in this regard. And since the ref to
> > > "id"
> > > doesn't resolve, a placeholder element is provided by XSD instead and that
> > > placeholder doesn't have a type.
> > >
> > > Adding the include to B.xsd is not a hack, it's required.
> > >
> > > Hayden Marchant wrote:
> > >
> > > > I have encountered a problem with the references schema resolving - below
> > > > I explain the scenario:
> > > >
> > > > I have 3 xsds - A.xsd, B.xsd, and C.xsd.
> > > >
> > > > Here are snippets of my schemas:
> > > >
> > > > A.xsd:
> > > >
> > > > <xs:include schemaLocation="B.xsd"/>
> > > > <xs:include schemaLocation="C.xsd"/>
> > > > <xs:element name="car">
> > > > <xs:complexType>
> > > > <xs:sequence>
> > > > <xs:element ref="service"/>
> > > > <xs:element ref="model"/>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > > </xs:element>
> > > >
> > > > B.xsd
> > > >
> > > > <xs:element name="service>
> > > > <complexTYpe>
> > > > <sequence>
> > > > <element ref="id"/>
> > > > </sequence>
> > > > </complexType>
> > > > </xs:element>
> > > >
> > > > C.xsd
> > > >
> > > > <xs:element name="id>....
> > > >
> > > > <xs:element name="model...
> > > >
> > > > Now, when validating A.xsd, then the whole group of schemas is valid,
> even
> > > > though the element reference 'id' that is referenced in B, is defined in
> > > > C, and there in no include/import of C. this works since in A.xsd we are
> > > > including both B and C, so as a whole, we have no problems.
> > > >
> > > > However, when I parse A.xsd with eclipse xsd, and I look at the
> > > > XSDElementDeclaration for 'id' in schema B, when I call
> > > > XSDElementDeclaration.getTypeDefinition() it returns null, and not the
> > > > XSDTypeDefintion for id (whether it be a complex type of simple type).
> > > >
> > > > At the moment I have hacked my B.xsd to have the include statement.
> > > >
> > > > Other parsers can cope with this problem, and XML Spy lets my open my
> > > > A.xsd is does not complain (but does complain when I open B.xsd)
> > > >
> > > > I hope that my explanation is clear.
> > >
> > > --
> > > Ed Merks
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem Including schemas [message #584043 is a reply to message #38305] |
Tue, 09 March 2004 16:28 |
Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
Sorry, my mistake. I was getting 2 different scenarios mixed up. we really
need to get XSD authors to use Eclipse instead of XML Spy - there are too
many illegal XSD's out there :)
Thanks,
Hayden
Ed Merks wrote:
> Hayden,
> I'm not sure where you are going with this? Given a document with a QName
in it,
> that QName either uses then namespace of the document or some other one; in
the
> former case, the document must define something with than name or must
include
> (directly or recursively) something with that name, in the later case, it
must have
> an import of that namespace. The document b.xsd doesn't define nor include
> something that defines "id", so it is invalid (and it won't suddenly become
valid
> by virtue of being included in a context that defines "id").
> Hayden Marchant wrote:
> > Ed,
> >
> > Clause 4 is referring to elements of different namespaces - i.e. it's
> > talking about <import> and not <include>. It seems that there is some
> > difference in the spec.
> >
> > Am I right?
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > Clause 4 of http://www.w3.org/TR/xmlschema-1/#src-resolve seems pretty
clear
> > > that for a QName to resolve within a schema document, the document
> > containing it
> > > must have an import of that QName's namespace. I don't have access to
the
> > book
> > > you mention, but the line you quote only seems to be saying something
about
> > how
> > > the schema is assembled and what names are available in that schema for
> > > validating XML instances as described in
> > > http://www.w3.org/TR/xmlschema-1/#cvc-resolve-instance Just because a
name
> > is
> > > available for validating an instance, doesn't mean it's visible in a
> > particular
> > > schema document without an import.
> >
> > > Hayden Marchant wrote:
> >
> > > > Ed,
> > > >
> > > > A question that I had over a year ago has come up again and I rummaged
> > > > through my correspondence with the Eclipse XSD newsgroups/forums and
found
> > > > the email below. It's a question concerning nested schemae. I have
> > > > included the email at the bottom of this mail.
> > > >
> > > > I took a look at the XML Schema spec and I think that the relevant
part is
> > > > at http://www.w3.org/TR/xmlschema-1/#compound-schema I took a look at
the
> > > > "Professional XML Schemas" published by Wrox, and on page 274 in
Chapter
> > > > 8, there is a bolded out sentence that says "If the schema we include
> > > > borrows from other schemas, we only have to reference the topmost
schema
> > > > for it to pull in other schemas it references".
> > > >
> > > > Thanks,
> > > > Hayden Marchant
> > > >
> > > > From 26 Jan 2003:
> > > >
> > > > Hayden,
> > > >
> > > > Sorry for the long delay answering forum questions...
> > > >
> > > > In the example below, B.xsd must have an include of C.xsd in order to
be
> > > > valid. Including B.xsd in A.xsd will not help to resolve the ref to
"id"
> > > > in
> > > > B.xsd. According to the spec (in my reading of it), for a QName to
resolve,
> > > > there must be an explicit import/include/redefine directly in the .xsd
> > > > file;
> > > > the "id" element simply isn't visible in B.xsd when the schema for
B.xsd is
> > > > being (transitively) processed. Perhaps other processors are more
tolerant
> > > > of
> > > > this error, perhaps even resolving the identifier via indirect
> > > > includes/imports, but XSD is strict in this regard. And since the ref
to
> > > > "id"
> > > > doesn't resolve, a placeholder element is provided by XSD instead and
that
> > > > placeholder doesn't have a type.
> > > >
> > > > Adding the include to B.xsd is not a hack, it's required.
> > > >
> > > > Hayden Marchant wrote:
> > > >
> > > > > I have encountered a problem with the references schema resolving -
below
> > > > > I explain the scenario:
> > > > >
> > > > > I have 3 xsds - A.xsd, B.xsd, and C.xsd.
> > > > >
> > > > > Here are snippets of my schemas:
> > > > >
> > > > > A.xsd:
> > > > >
> > > > > <xs:include schemaLocation="B.xsd"/>
> > > > > <xs:include schemaLocation="C.xsd"/>
> > > > > <xs:element name="car">
> > > > > <xs:complexType>
> > > > > <xs:sequence>
> > > > > <xs:element ref="service"/>
> > > > > <xs:element ref="model"/>
> > > > > </xs:sequence>
> > > > > </xs:complexType>
> > > > > </xs:element>
> > > > >
> > > > > B.xsd
> > > > >
> > > > > <xs:element name="service>
> > > > > <complexTYpe>
> > > > > <sequence>
> > > > > <element ref="id"/>
> > > > > </sequence>
> > > > > </complexType>
> > > > > </xs:element>
> > > > >
> > > > > C.xsd
> > > > >
> > > > > <xs:element name="id>....
> > > > >
> > > > > <xs:element name="model...
> > > > >
> > > > > Now, when validating A.xsd, then the whole group of schemas is valid,
> > even
> > > > > though the element reference 'id' that is referenced in B, is
defined in
> > > > > C, and there in no include/import of C. this works since in A.xsd we
are
> > > > > including both B and C, so as a whole, we have no problems.
> > > > >
> > > > > However, when I parse A.xsd with eclipse xsd, and I look at the
> > > > > XSDElementDeclaration for 'id' in schema B, when I call
> > > > > XSDElementDeclaration.getTypeDefinition() it returns null, and not
the
> > > > > XSDTypeDefintion for id (whether it be a complex type of simple
type).
> > > > >
> > > > > At the moment I have hacked my B.xsd to have the include statement.
> > > > >
> > > > > Other parsers can cope with this problem, and XML Spy lets my open my
> > > > > A.xsd is does not complain (but does complain when I open B.xsd)
> > > > >
> > > > > I hope that my explanation is clear.
> > > >
> > > > --
> > > > Ed Merks
|
|
|
Goto Forum:
Current Time: Tue Apr 23 10:45:57 GMT 2024
Powered by FUDForum. Page generated in 0.03992 seconds |
] 
Search
Help
Register
Login
Home
