Re: Possible errors in XSV

Eddie Robertsson <eddie@allette.com.au> writes:

> XSV Version: XSV 1.173.2.15/1.74.2.20 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?

Still not implemented, unlikely to be implemented in the near future.
'The XSV group' is two people, both of whom have a lot of other
responsibilities, sorry.

> 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.
> 
> substGroup.xsd:
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema targetNamespace="http://www.substgroup.org"
> xmlns:s="http://www.substgroup.org"
> xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
> elementFormDefault="qualified">
>  <xsd:element name="substGroup">
>   <xsd:complexType>
>    <xsd:sequence>
>     <xsd:element ref="s:integer"/>
>    </xsd:sequence>
>   </xsd:complexType>
>  </xsd:element>
>  <xsd:element name="integer" type="xsd:integer"/>
>  <xsd:element name="string" type="xsd:string"
> substitutionGroup="s:integer"/>
> </xsd:schema>
> 
> substGroup.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <substGroup xmlns="http://www.substgroup.org"
> xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
> xsi:schemaLocation="http://www.substgroup.org substGroup.xsd">
>  <integer>234</integer>
> </substGroup>
> 
> 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)

This is a fixed bug, you need the newer packaged-up executable [1]:

<xsv docElt='{http://www.substgroup.org}substGroup'
instanceAssessed='true' instanceErrors='0' rootType='[Anonymous]'
schemaDocs='substGroup.xsd' schemaErrors='1'
schemaLocs='http://www.substgroup.org -> substGroup.xsd'
target='/projects/ltg/users/ht/xml/xmlschema/monk/substGroup.xml'
validation='strict' version='XSV 1 .173.2.15.2.4/1.74.2.25 of
2001/01/03 19:13:19' xmlns='http://www.w3.org/2000/05/xsv'>

<schemaError char='50' line='13' phase='instance'
resource='file:///projects/ltg/users/ht/xml/xmlschema/monk/substGroup.xsd'>type
{http://www.w3.org/2000/10/XML Schema}string not subtype of type
{http://www.w3.org/2000/10/XMLSchema}integer of exemplar
{http://www.substgroup.org}:integer</schemaError>

</xsv>

> 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:
> 
> finalTest.xsd:
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema targetNamespace="http://www.finalTest.org"
> xmlns:f="http://www.finalTest.org"
> xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
> elementFormDefault="qualified">
>  <xsd:element name="finalTest">
>   <xsd:complexType>
>    <xsd:sequence>
>     <xsd:element ref="f:address"/>
>    </xsd:sequence>
>   </xsd:complexType>
>  </xsd:element>
>  <xsd:complexType name="addressType" final="#all">
>   <xsd:annotation>
>    <xsd:documentation>You can change the final="#all" to block="#all"
> and the schema is still valid...</xsd:documentation>
>   </xsd:annotation>
>   <xsd:all>
>    <xsd:element name="street" maxOccurs="unbounded">
>     <xsd:complexType mixed="true">
>      <xsd:attribute name="code" type="xsd:ID"/>
>     </xsd:complexType>
>    </xsd:element>
>    <xsd:element name="state" type="xsd:string"/>
>  </xsd:all>
>  </xsd:complexType>
>  <xsd:complexType name="myAddress">
>   <xsd:complexContent>
>    <xsd:extension base="f:addressType">
>     <xsd:sequence>
>      <xsd:element name="unit" type="xsd:string"/>
>     </xsd:sequence>
>    </xsd:extension>
>   </xsd:complexContent>
>  </xsd:complexType>
>  <xsd:element name="address" type="f:addressType"/>
>  <xsd:element name="myAddress" type="f:myAddress"
> substitutionGroup="f:address"/>
> </xsd:schema>
> 
> finalTest.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <finalTest xmlns="http://www.finalTest.org"
> xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
> xsi:schemaLocation="http://www.finalTest.org finalTest.xsd">
>  <myAddress>
>   <street code="S-2000">York street</street>
>   <street code="S-2000">York street</street>
>   <unit>31</unit>
>  </myAddress>
> </finalTest>
> 
> 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.

This is a bug in XSV wrt #all, if you use final='extension
restriction' you will get the expected error.

> 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.

You're right, XSV should be checking this but isn't.

> * Although the element state is declared in the all group the instance
> is still valid without a state element in the instance.

You're right, XSV should be checking this but isn't.

> 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...)

That's correct, key/keyref is implemented but ID/IDREF is not.

> 5) When I ran the following instance with XSV I received a bug report:
> 
> xsiType.xsd:
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema targetNamespace="http://cars.example.com/schema"
> xmlns="http://cars.example.com/schema"
> xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
>  <xsd:complexType name="Vehicle" abstract="true"/>
>  <xsd:complexType name="Car">
>   <xsd:complexContent>
>    <xsd:extension base="Vehicle">
>     <xsd:sequence>
>      <xsd:element name="Make" type="xsd:string"/>
>     </xsd:sequence>
>    </xsd:extension>
>   </xsd:complexContent>
>  </xsd:complexType>
>  <xsd:complexType name="Plane">
>   <xsd:complexContent>
>    <xsd:extension base="Vehicle"/>
>   </xsd:complexContent>
>  </xsd:complexType>
>  <xsd:element name="transport" type="Vehicle"/>
> </xsd:schema>
> 
> xsiType.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <transport xmlns="http://cars.example.com/schema"
> xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
> xsi:schemaLocation="http://cars.example.com/schema xsiType.xsd"
> xsi:type="Car">
>  <Make>Ford</Make>
> </transport>
> 
> The output from XSV was:
> <?xml version='1.0'?>
> <xsv crash='true' docElt='{http://cars.example.com/schema}transport'

</snip>

Fixed in latest version.

> I also have a final question for the XSV group. Do you have a schema or
> DTD for the error logs?

Surely there should be, but there aren't :-(

> 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.

Sorry.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

Received on Thursday, 18 January 2001 04:38:09 UTC