You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Peter Aberline (JIRA)" <xe...@xml.apache.org> on 2006/08/29 10:55:30 UTC
[jira] Created: (XERCESC-1627) Schema validator sensitive to the
order of xsd:import and xsd:include elements.
Schema validator sensitive to the order of xsd:import and xsd:include elements.
-------------------------------------------------------------------------------
Key: XERCESC-1627
URL: http://issues.apache.org/jira/browse/XERCESC-1627
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (Schema) (Xerces 1.5 or up only)
Affects Versions: 1.5, 1.6.0, 1.7.0
Environment: Windows XP SR2
Reporter: Peter Aberline
Priority: Minor
Attachments: schema_validator_bug.zip
Xerces validating schema parser appears to be intolerant of the order of xsd:import and xsd:include elements.
This can be demonstrated with the the DOMCount program:
DOMCount -s -n -v=always CSW_caps.xml
This causes validation errors by the schema validator unable to resolve types included in owsGetCapabilities. Swapping the order of the
<xsd:include> to after the <xsd:import> (lines 22-25 of CSW-discovery.xsd) solves the validation error.
The fragment of XMLSchema.xsd shown below suggests to me that import and include elements can be in any order?
http://www.w3.org/2001/XMLSchema.xsd:
<xs:element name="schema" id="schema">
<xs:annotation>
<xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-schema"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:openAttrs">
<xs:sequence>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="xs:include"/>
<xs:element ref="xs:import"/>
<xs:element ref="xs:redefine"/>
<xs:element ref="xs:annotation"/>
</xs:choice>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:group ref="xs:schemaTop"/>
<xs:element ref="xs:annotation" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
...
...
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Updated: (XERCESC-1627) Schema validator sensitive to the
order of xsd:import and xsd:include elements.
Posted by "Alberto Massari (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESC-1627?page=all ]
Alberto Massari updated XERCESC-1627:
-------------------------------------
Affects Version/s: 2.5.0
2.6.0
2.7.0
(was: 1.5)
(was: 1.6.0)
(was: 1.7.0)
> Schema validator sensitive to the order of xsd:import and xsd:include elements.
> -------------------------------------------------------------------------------
>
> Key: XERCESC-1627
> URL: http://issues.apache.org/jira/browse/XERCESC-1627
> Project: Xerces-C++
> Issue Type: Bug
> Components: Validating Parser (Schema) (Xerces 1.5 or up only)
> Affects Versions: 2.5.0, 2.6.0, 2.7.0
> Environment: Windows XP SR2
> Reporter: Peter Aberline
> Priority: Minor
> Attachments: schema_validator_bug.zip
>
>
> Xerces validating schema parser appears to be intolerant of the order of xsd:import and xsd:include elements.
> This can be demonstrated with the the DOMCount program:
> DOMCount -s -n -v=always CSW_caps.xml
> This causes validation errors by the schema validator unable to resolve types included in owsGetCapabilities. Swapping the order of the
> <xsd:include> to after the <xsd:import> (lines 22-25 of CSW-discovery.xsd) solves the validation error.
> The fragment of XMLSchema.xsd shown below suggests to me that import and include elements can be in any order?
> http://www.w3.org/2001/XMLSchema.xsd:
> <xs:element name="schema" id="schema">
> <xs:annotation>
> <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-schema"/>
> </xs:annotation>
> <xs:complexType>
> <xs:complexContent>
> <xs:extension base="xs:openAttrs">
> <xs:sequence>
> <xs:choice minOccurs="0" maxOccurs="unbounded">
> <xs:element ref="xs:include"/>
> <xs:element ref="xs:import"/>
> <xs:element ref="xs:redefine"/>
> <xs:element ref="xs:annotation"/>
> </xs:choice>
> <xs:sequence minOccurs="0" maxOccurs="unbounded">
> <xs:group ref="xs:schemaTop"/>
> <xs:element ref="xs:annotation" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> ...
> ...
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:element>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Commented: (XERCESC-1627) Schema validator sensitive to the
order of xsd:import and xsd:include elements.
Posted by "Peter Aberline (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESC-1627?page=comments#action_12431255 ]
Peter Aberline commented on XERCESC-1627:
-----------------------------------------
My apologies the version numbers should have read 2.5, 2.6 and 2.7, not the older 1.x series.
Also the zip file posted with the original report contains an example instance document and all related schemas.
> Schema validator sensitive to the order of xsd:import and xsd:include elements.
> -------------------------------------------------------------------------------
>
> Key: XERCESC-1627
> URL: http://issues.apache.org/jira/browse/XERCESC-1627
> Project: Xerces-C++
> Issue Type: Bug
> Components: Validating Parser (Schema) (Xerces 1.5 or up only)
> Affects Versions: 1.5, 1.6.0, 1.7.0
> Environment: Windows XP SR2
> Reporter: Peter Aberline
> Priority: Minor
> Attachments: schema_validator_bug.zip
>
>
> Xerces validating schema parser appears to be intolerant of the order of xsd:import and xsd:include elements.
> This can be demonstrated with the the DOMCount program:
> DOMCount -s -n -v=always CSW_caps.xml
> This causes validation errors by the schema validator unable to resolve types included in owsGetCapabilities. Swapping the order of the
> <xsd:include> to after the <xsd:import> (lines 22-25 of CSW-discovery.xsd) solves the validation error.
> The fragment of XMLSchema.xsd shown below suggests to me that import and include elements can be in any order?
> http://www.w3.org/2001/XMLSchema.xsd:
> <xs:element name="schema" id="schema">
> <xs:annotation>
> <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-schema"/>
> </xs:annotation>
> <xs:complexType>
> <xs:complexContent>
> <xs:extension base="xs:openAttrs">
> <xs:sequence>
> <xs:choice minOccurs="0" maxOccurs="unbounded">
> <xs:element ref="xs:include"/>
> <xs:element ref="xs:import"/>
> <xs:element ref="xs:redefine"/>
> <xs:element ref="xs:annotation"/>
> </xs:choice>
> <xs:sequence minOccurs="0" maxOccurs="unbounded">
> <xs:group ref="xs:schemaTop"/>
> <xs:element ref="xs:annotation" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> ...
> ...
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:element>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
inconsistent whiteSpace handling for list type in different versions of Xerces
Posted by Frank Zhou <fc...@yahoo.com>.
Hi All,
A few days ago I posted this message, but I haven't
got any response. I still would like to seek advice on
this one, so I re-posted it again.
Thanks much.
====================================
I've encountered a problem with whiteSpace handling
for list type. I noticed that the behavior is changed
from Xerces library 1.7 to Xerces 2.7.
Here is the detail:
I have a simple type defined as this:
<element name="test" nillable="true">
<simpleType>
<restriction>
<simpleType>
<list itemType="int" />
</simpleType>
<minLength value="2" />
</restriction>
</simpleType>
</element>
And the instance is like this:
<test>
51 32 59
</test>
In Xerces 1.7, when I turned on schema validation, I
got "51 32 59" as the character data for element test,
and if validation is turned off, I got the whole
thing, including the leading/ending carriage return
and spaces.
However, in Xerces 2.7, not matter validation is
turned on or off, I always got the whole thing. This
does not seem right to me, my understanding of the XML
schema spec is that facet whileSpace can only be
"collapse" for list type. So I am expecting either a
validation error for this case or the same behavior as
Xerces 1.7.
Can anybody provide suggestions?
Thanks in advance.
Frank
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
inconsistent whiteSpace handling for list type in different versions of Xerces
Posted by Frank Zhou <fc...@yahoo.com>.
Hi All,
I've encountered a problem with whiteSpace handling
for list type. I noticed that the behavior is changed
from Xerces library 1.7 to Xerces 2.7.
Here is the detail:
I have a simple type defined as this:
<element name="test" nillable="true">
<simpleType>
<restriction>
<simpleType>
<list itemType="int" />
</simpleType>
<minLength value="2" />
</restriction>
</simpleType>
</element>
And the instance is like this:
<test>
51 32 59
</test>
In Xerces 1.7, when I turned on schema validation, I
got "51 32 59" as the character data for element test,
and if validation is turned off, I got the whole
thing, including the leading/ending carriage return
and spaces.
However, in Xerces 2.7, not matter validation is
turned on or off, I always got the whole thing. This
does not seem right to me, my understanding of the XML
schema spec is that facet whileSpace can only be
"collapse" for list type. So I am expecting either a
validation error for this case or the same behavior as
Xerces 1.7.
Can anybody provide suggestions?
Thanks in advance.
Frank
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Commented: (XERCESC-1627) Schema validator sensitive to the
order of xsd:import and xsd:include elements.
Posted by "Alberto Massari (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESC-1627?page=comments#action_12431253 ]
Alberto Massari commented on XERCESC-1627:
------------------------------------------
Please download and test the latest version of Xerces (1.7 is very old,the latest is 2.7); also, attach the XMLSchema involved.
> Schema validator sensitive to the order of xsd:import and xsd:include elements.
> -------------------------------------------------------------------------------
>
> Key: XERCESC-1627
> URL: http://issues.apache.org/jira/browse/XERCESC-1627
> Project: Xerces-C++
> Issue Type: Bug
> Components: Validating Parser (Schema) (Xerces 1.5 or up only)
> Affects Versions: 1.5, 1.6.0, 1.7.0
> Environment: Windows XP SR2
> Reporter: Peter Aberline
> Priority: Minor
> Attachments: schema_validator_bug.zip
>
>
> Xerces validating schema parser appears to be intolerant of the order of xsd:import and xsd:include elements.
> This can be demonstrated with the the DOMCount program:
> DOMCount -s -n -v=always CSW_caps.xml
> This causes validation errors by the schema validator unable to resolve types included in owsGetCapabilities. Swapping the order of the
> <xsd:include> to after the <xsd:import> (lines 22-25 of CSW-discovery.xsd) solves the validation error.
> The fragment of XMLSchema.xsd shown below suggests to me that import and include elements can be in any order?
> http://www.w3.org/2001/XMLSchema.xsd:
> <xs:element name="schema" id="schema">
> <xs:annotation>
> <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-schema"/>
> </xs:annotation>
> <xs:complexType>
> <xs:complexContent>
> <xs:extension base="xs:openAttrs">
> <xs:sequence>
> <xs:choice minOccurs="0" maxOccurs="unbounded">
> <xs:element ref="xs:include"/>
> <xs:element ref="xs:import"/>
> <xs:element ref="xs:redefine"/>
> <xs:element ref="xs:annotation"/>
> </xs:choice>
> <xs:sequence minOccurs="0" maxOccurs="unbounded">
> <xs:group ref="xs:schemaTop"/>
> <xs:element ref="xs:annotation" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> ...
> ...
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:element>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Closed: (XERCESC-1627) Schema validator sensitive to the
order of xsd:import and xsd:include elements.
Posted by "Boris Kolpackov (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boris Kolpackov closed XERCESC-1627.
------------------------------------
Resolution: Fixed
Fix Version/s: 3.1.0
With the multiple import enabled, I get the same output with the original schema and with the swapped include/import. There are some other schema and validation errors but I am assuming the original bug is fixed.
> Schema validator sensitive to the order of xsd:import and xsd:include elements.
> -------------------------------------------------------------------------------
>
> Key: XERCESC-1627
> URL: https://issues.apache.org/jira/browse/XERCESC-1627
> Project: Xerces-C++
> Issue Type: Bug
> Components: Validating Parser (XML Schema)
> Affects Versions: 2.5.0, 2.6.0, 2.7.0
> Environment: Windows XP SR2
> Reporter: Peter Aberline
> Priority: Minor
> Fix For: 3.1.0
>
> Attachments: schema_validator_bug.zip
>
>
> Xerces validating schema parser appears to be intolerant of the order of xsd:import and xsd:include elements.
> This can be demonstrated with the the DOMCount program:
> DOMCount -s -n -v=always CSW_caps.xml
> This causes validation errors by the schema validator unable to resolve types included in owsGetCapabilities. Swapping the order of the
> <xsd:include> to after the <xsd:import> (lines 22-25 of CSW-discovery.xsd) solves the validation error.
> The fragment of XMLSchema.xsd shown below suggests to me that import and include elements can be in any order?
> http://www.w3.org/2001/XMLSchema.xsd:
> <xs:element name="schema" id="schema">
> <xs:annotation>
> <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-schema"/>
> </xs:annotation>
> <xs:complexType>
> <xs:complexContent>
> <xs:extension base="xs:openAttrs">
> <xs:sequence>
> <xs:choice minOccurs="0" maxOccurs="unbounded">
> <xs:element ref="xs:include"/>
> <xs:element ref="xs:import"/>
> <xs:element ref="xs:redefine"/>
> <xs:element ref="xs:annotation"/>
> </xs:choice>
> <xs:sequence minOccurs="0" maxOccurs="unbounded">
> <xs:group ref="xs:schemaTop"/>
> <xs:element ref="xs:annotation" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> ...
> ...
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:element>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org