RE: XSV - possible bug with XSV type checking

I have been using XSV for the first time and had also run into this problem.
I think that I understand why this is not an XSV bug, but here is another
variation on the same theme.  Consider the validation of this .xml file:
----------------
<po:edt
  xmlns:po="http://www.emilygraham.com/java/other/editor2.xsd">true</po:edt>

----------------
AGAINST this .xsd file (editor2.xsd):
----------------

<schema targetNamespace="http://www.emilygraham.com/java/other/editor2.xsd"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:r="http://www.emilygraham.com/java/other/editor2.xsd"
        elementFormDefault="unqualified">

 <element name="edit">
  <simpleType>
        <restriction base="NMTOKEN">
          <enumeration value="true"/>
          <enumeration value="false"/>
        </restriction>
  </simpleType>
 </element>
 
</schema>

-----------------

Notice that in the .xml file, I have spelled the "edit" element incorrectly.
I have specified it with a fully qualified name in the xml file (po:edt).
When the "edt" element is NOT FOUND in the xsd document specified by the po:
qualifier, shouldn't validation fail?  It seems like a fully qualified
"undefined" variable to me.  Instead of an error, XSV just goes into "lax"
validation mode and says that everything is ok (because the file is well
formed).  This means that the po:edt never gets validated against the
http://www.emilygraham.com/java/other/editor2.xsd file.  

Tom Preston


-----Original Message-----
From: ht@cogsci.ed.ac.uk [mailto:ht@cogsci.ed.ac.uk]
Sent: Thursday, November 29, 2001 12:16 PM
To: Ian.Mockford
Cc: 'xmlschema-dev@w3.org'
Subject: Re: XSV - possible bug with XSV type checking


"Ian.Mockford" <Ian.Mockford@rrl.co.uk> writes:

> Not sure if this is a bug with XSV or a misapprehension on my part,
> but if I validate a schema with lines like:

>    <xsd:attribute name="id" type="xsd:ForceBreak" use="required" />
>    <xsd:attribute name="year" type="xsd:integer" use="required" />
> 
> I would expect a failure because I wouldn't expect
> [type="xsd:ForceBreak"] to be acceptable because it is not an xsd:
> type.  This came to light when I had a schema that contained
> type="xsd:real", which another tool (Xerces?) did not like (quite
> rightly by my interpretation of XML Schema spec).

I presume you're saying that XSV did _not_ complain, and that's what
surprised you.

> So I would be interested in knowing whether this is a bug or a known
> behaviour that has a sensible reason behind it. If the latter, it
> might be worth posting something with the XSV to explain it.

This is not a bug, it's the way W3C XML Schema is defined.  There are
two ways in which the first attribute above is not broken:

 1) It's valid per the schema for schemas: it has only allowed
    attributes, it has all the required attributes, the values of the
    attributes satisfy their type definitions.

 2) It _may_ be used in a complex type definition which is never
    actually needed in the validation of a particular instance.

So if you just asked XSV to validate your schema document, it doesn't
complain.  Perhaps when you came to actually use it, you'd also supply
a schema document which defined the missing ForceBreak type.  On its
own, the document is fine as a schema document, and it _could_
contribute to a well-specified schema.

If you have XSV installed locally you can use the -i flag to signal
you would like XSV to assume that the schema documents it's looking at
are _all_ the schema documents it would have for some validation
episode.  In that case you would get the error.

If you try to _use_ that schema document to validate an instance, it
may or may not complain, depending on the instance.

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, 29 November 2001 17:09:36 UTC