W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2001

Possible errors in XSV

From: Eddie Robertsson <eddie@allette.com.au>
Date: Thu, 18 Jan 2001 14:30:49 +1100
Message-ID: <3A666368.3615D931@allette.com.au>
To: XSD <xmlschema-dev@w3.org>
Hi all,

I'm currently working on a course in XSD and to get as familiar as
possible with the specification I've spent the last couple of days
testing different examples with different validators (XML Spy and XSV).
During my testing I have found a couple of issues with XSV that might be
an error or maybe the feature just haven't been implemented yet. Of
cause it could simply be that I don't understand the spec and please do
correct me if this is the case. Anyway, I thought I'd send the
information to see if anyone else has discovered the same thing and if
the XSV group is aware of the issues. Each report will be followed but
an example schema and instance.

XSV Version: XSV of 2000/12/16 12:10:29

1) Data type validation doesn't seem to work at all. I looked at the XSV
update site (http://www.ltg.ed.ac.uk/~ht/xsv-status.html) and saw this
"Simple type conformance, other than enumerations and max/min for
numeric types " so I guess this may not be implemented yet. If this is
the case does the XSV group know when this may be implemented?

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.datatypes.org"
 <xsd:element name="dataTypes">
    <xsd:element name="uriTest" type="xsd:uriReference"/>
    <xsd:element name="patternTest">
      <xsd:restriction base="xsd:string">
       <xsd:pattern value="\d{6}-\d{4}"/>

<?xml version="1.0" encoding="UTF-8"?>
<dataTypes xmlns="http://www.datatypes.org"
xsi:schemaLocation="http://www.datatypes.org dataTypes.xsd">
 <uriTest>Test text</uriTest>

XSV generates no errors for the above example despite the mismatch of
the values for the elements <uriTest> and <patternTest>.

2) Type check for substitutionGroup. According to the spec "Elements in
a substituition group must have the same type as the head element, or
they can have a type that has been derived from the head element's
type". XSV doesn't seem to restrict the types of the elements in the
substitution group but I guess if 1) hasn't been implemented yet this is
an effect of that.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.substgroup.org"
 <xsd:element name="substGroup">
    <xsd:element ref="s:integer"/>
 <xsd:element name="integer" type="xsd:integer"/>
 <xsd:element name="string" type="xsd:string"

<?xml version="1.0" encoding="UTF-8"?>
<substGroup xmlns="http://www.substgroup.org"
xsi:schemaLocation="http://www.substgroup.org substGroup.xsd">

XSV doesn't generate an error for this example although the string
element (type xsd:string) can be used to substitute the integer element
(type xsd:integer)

3) Use of the final and block attributes in complexType definitions.
4) The all element doesn't seem to work properly
5) Duplicate ID attributes allowed in the instance

3, 4 and 5 exist in the following example:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.finalTest.org"
 <xsd:element name="finalTest">
    <xsd:element ref="f:address"/>
 <xsd:complexType name="addressType" final="#all">
   <xsd:documentation>You can change the final="#all" to block="#all"
and the schema is still valid...</xsd:documentation>
   <xsd:element name="street" maxOccurs="unbounded">
    <xsd:complexType mixed="true">
     <xsd:attribute name="code" type="xsd:ID"/>
   <xsd:element name="state" type="xsd:string"/>
 <xsd:complexType name="myAddress">
   <xsd:extension base="f:addressType">
     <xsd:element name="unit" type="xsd:string"/>
 <xsd:element name="address" type="f:addressType"/>
 <xsd:element name="myAddress" type="f:myAddress"

<?xml version="1.0" encoding="UTF-8"?>
<finalTest xmlns="http://www.finalTest.org"
xsi:schemaLocation="http://www.finalTest.org finalTest.xsd">
  <street code="S-2000">York street</street>
  <street code="S-2000">York street</street>

XSV doesn't generate any errors for this instance but I see several.
First, the use of the final attribute for the addressType should
restrict derivation using this type as a base but it seems to work fine
anyway. Second, the element address uses the xsd:all element which has
two issues:

* According to the spec an element in an all group can only have
minOccurs and maxOccurs equal to 0 or 1 but in the above example the
street element have maxOccurs=unbounded.
* Although the element state is declared in the all group the instance
is still valid without a state element in the instance.

Third, the attribute code in the street element is declared with the
xsd:ID type but still the above instance is valid (I guess this comes
back to the issue of the data types in the first question though...)

5) When I ran the following instance with XSV I received a bug report:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://cars.example.com/schema"
 <xsd:complexType name="Vehicle" abstract="true"/>
 <xsd:complexType name="Car">
   <xsd:extension base="Vehicle">
     <xsd:element name="Make" type="xsd:string"/>
 <xsd:complexType name="Plane">
   <xsd:extension base="Vehicle"/>
 <xsd:element name="transport" type="Vehicle"/>

<?xml version="1.0" encoding="UTF-8"?>
<transport xmlns="http://cars.example.com/schema"
xsi:schemaLocation="http://cars.example.com/schema xsiType.xsd"

The output from XSV was:
<?xml version='1.0'?>
<xsv crash='true' docElt='{http://cars.example.com/schema}transport'
instanceAssessed='true' instanceErrors='0'
rootType='{http://cars.example.com/schema}:Vehicle' schemaErrors='0'
schemaLocs='http://cars.example.com/schema -> xsiType.xsd'
target='file:/E:/Work/XML Schema/Errors/xsiType.xml' validation='strict'
version='XSV of 2000/1
2/16 12:10:29' xmlns='http://www.w3.org/2000/05/xsv'>
<importAttempt URI='file:/E:/Work/XML Schema/Errors/xsiType.xsd'
xample.com/schema' outcome='success'/>
<bug>validator crash during validation</bug>
Traceback (most recent call last):
  File "<string>", line 1115, in ?
__main__.SchemaValidationError: Traceback (most recent call last):
  File "<string>", line 764, in runit
  File "<string>", line 53, in validate
  File "<string>", line 85, in validateElement

I also have a final question for the XSV group. Do you have a schema or
DTD for the error logs?
I'm planning on writing an XSLT stylesheet to simply output the error
information you really and it's a bit hard when I don't know what to
expect from the error log. I know there is a stylesheet provided with
XSV but I just want simple information to std output.

Thanks for any comments
Received on Wednesday, 17 January 2001 22:28:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:14:49 UTC