OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Type Derivation by Restriction



"Winkowski, Daniel" <winkowski@mitre.org> writes:

> This is a question regarding XML Schema type derivation by restriction. I
> have a set of code lists that provide valid "domain values" for some set of
> fields. These code lists may be reused in various fields in whole or by a
> strict subset. It seemed natural to model the code lists as simple
> enumerated types and each field as a complex type that may include further
> restriction. Example below.
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <schema targetNamespace="http://www.mitre.org/test"
> xmlns="http://www.w3.org/2000/10/XMLSchema"
> xmlns:t="http://www.mitre.org/test" elementFormDefault="qualified">
>   <element name="Field34" type="t:Codelist58-Type2">
>     <annotation>
>       <documentation>Test of derivation by restriction</documentation>
>     </annotation>
>   </element>
>   <complexType name="Codelist58-Type2">
>     <annotation>
>       <documentation>LATITUDINAL HEMISPHERE</documentation>
>     </annotation>
>     <simpleContent>
>       <restriction base="t:Codelist58">
>         <enumeration value="N"/>
>         <enumeration value="S"/>
>       </restriction>
>     </simpleContent>
>   </complexType>
>   <simpleType name="Codelist58">
>     <annotation>
>       <documentation>HEMISPHERES</documentation>
>     </annotation>
>     <restriction base="string">
>       <enumeration value="N"/>
>       <enumeration value="S"/>
>       <enumeration value="E"/>
>       <enumeration value="W"/>
>     </restriction>
>   </simpleType>
> </schema>
> 
> The schema validates in both  XML Spy 3.5 and - XSV 1.175/1.85. A test
> document is shown below:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <Field34 xmlns="http://www.mitre.org/test"
> xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
> xsi:schemaLocation="http://www.mitre.org/test STestFF.xml">S</Field34>
> 
> XSV 1.175/1.85 validates the instance documents without errors when
> Field34's content is "S" but reports errors when it is "E" which is just
> what I would expect. 
> 
> XML Spy also validates the instance document for "S" but also for "E" which
> was unexpected. When I put in "Q" it reported that the value does not match
> the facet enumeration "N S E W N S" which suggests it is combining all
> enumerations! 
> 
> So which is right?

Looks like XML Spy is confusing patterns with enumerations, or
something like that.  In any case, the spec. is clear on this, the
only valid values for Field34 are 'N' and 'S'.

> Further testing revealed that the restriction was not behaving as I
> expected. If I added an additional enumeration "BAD" to the restricted
> Codelist58-Type2 based on Codelist58 no validation complaints occur. Is this
> proper? I expected restriction to be strict and not allow additions
> (extensions) to the content model.

That's correct, but XSV isn't checking that yet, as signalled on the
status page [1].

> <complexType name="Codelist58-Type2">
>     <annotation>
>       <documentation>LATITUDINAL HEMISPHERE</documentation>
>     </annotation>
>     <simpleContent>
>       <restriction base="t:Codelist58">
>         <enumeration value="N"/>
>         <enumeration value="S"/>
>         <enumeration value="BAD"/>
>       </restriction>
>     </simpleContent>
>   </complexType>

Not valid, sorry not being caught yet.

ht

[1] http://www.ltg.ed.ac.uk/~ht/xsv-status.html
-- 
  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/