AW: [xsd-users] xerces validation problem

Klima Georg G.Klima at durst-online.at
Thu Jul 11 09:19:00 EDT 2013


Hi Boris,

thank you, you saved my day! It seems now clear to me!

Simply in the chain of extension/restriction (viewed from base to derived) there must not be any extension after restriction!

-----------------------------------------
CASE A (valid):

Base
 |
(extension)
 |
Derived1
 |
(restriction)
 |
Derived2

----------------------------------------
CASE B (invalid):

Base
 |
(restriction)
 |
Derived1
 |
(extension)
 |
Derived2
-----------------------------------------

While case A is valid case B isn't. After a restriction a type can't be extended anymore, since the last type before the first restriction defines the maximal "content/specification".

LG
Georg




-----Ursprüngliche Nachricht-----
Von: Boris Kolpackov [mailto:boris at codesynthesis.com] 
Gesendet: Donnerstag, 11. Juli 2013 14:05
An: Klima Georg
Cc: xsd-users at codesynthesis.com
Betreff: Re: [xsd-users] xerces validation problem

Hi Georg,

Klima Georg <G.Klima at durst-online.at> writes:

> ERROR: element 'Print' has type that does not derive from type of 
> corresponding element in the base
> 
> 		<xs:sequence>
> 			<xs:element name="Print" type="durst:PrintPrimitive_at" minOccurs="1" maxOccurs="unbounded"/>
> 		</xs:sequence>
>
> 	<xs:restriction base="durst:SlotBase_at">
> 		<xs:sequence>
>			<xs:element name="Print" type="durst:SlotPrintPrimitive_at" minOccurs="1" maxOccurs="unbounded"/>
> 		</xs:sequence>
> 	</xs:restriction>
>
> 	<xs:complexType name="SlotPrintPrimitive_at" abstract="true">
> 		<xs:complexContent>
> 	 		<xs:extension base="durst:PrintPrimitive_at">

Your SlotUnrestricted_vt derives by restriction from PrinterComponent_at.
This means that any instance of SlotUnrestricted_vt should also be valid per PrinterComponent_at. However, your SlotPrintPrimitive_at is an extension of PrintPrimitive_at (it adds extra attributes). As a result, it cannot be used in this restriction (it allows more than the base).


> libxml (xmllint) and qt (xmlpatternsvalidator) perfectly accept this 
> construct. - Who is wrong?

While the error message is slightly misleading, Xerces-C++ is correct and the other two validators are broken.

Boris



More information about the xsd-users mailing list