- From: Krzysztof FF <Krzysztof.Finowicki@tessel.pl>
- Date: Thu, 31 Dec 2009 03:49:18 -0800 (PST)
- To: xmlschema-dev@w3.org
I have still problems with derivation by restriction (certainly I'm not the first one). Problem is concerned with concept of parallel deriving of components and containers, like described in: http://www.xfront.com/ElementHierarchy.html I've tried to isolate the problem to minimal amount of code, which I'm trying to explain below. Let's start with elements and types defined in base schema, sys.xsd: <schema targetNamespace="http://www.org.com/SYS" xmlns:sys="http://www.org.com/SYS" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <element name="quantity" type="sys:QuantityType"/> <simpleType name="QuantityType"> <restriction base="integer"> <minInclusive value="0"/> </restriction> </simpleType> <complexType name="BaseType11"> <sequence> <element ref="sys:quantity"/> </sequence> </complexType> <complexType name="BaseType0u"> <sequence> <element ref="sys:quantity" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> </schema> There is simple element "quantity" which is used in two alternative definitions of complex types: BaseType11 (with default values of minOccurs and maxOccurs equal to "1") and BaseType0u (with minOccurs="0" maxOccurs="unbounded"). Now I want to define some derived types in derived schema, app.xsd: <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.org.com/APP" xmlns:app="http://www.org.com/APP" xmlns:sys="http://www.org.com/SYS" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <import namespace="http://www.org.com/SYS" schemaLocation="sys.xsd"/> <element name="restrictedQuantity" type="app:RestrictedQuantityType" substitutionGroup="sys:quantity"/> <simpleType name="RestrictedQuantityType"> <restriction base="sys:QuantityType"> <maxInclusive value="10"/> </restriction> </simpleType> <complexType name="DerivedType11VALID"> <complexContent> <restriction base="sys:BaseType11"> <sequence> <element ref="app:restrictedQuantity"/> </sequence> </restriction> </complexContent> </complexType> <complexType name="DerivedType0uVALID"> <complexContent> <restriction base="sys:BaseType0u"> <sequence> <element ref="app:restrictedQuantity"/> </sequence> </restriction> </complexContent> </complexType> <complexType name="DerivedType0uINVALID"> <complexContent> <restriction base="sys:BaseType0u"> <sequence> <element ref="app:restrictedQuantity" minOccurs="0" maxOccurs="unbounded"/> </sequence> </restriction> </complexContent> </complexType> <complexType name="DerivedType12VALID"> <complexContent> <restriction base="sys:BaseType0u"> <sequence> <element ref="sys:quantity" minOccurs="1" maxOccurs="2"/> </sequence> </restriction> </complexContent> </complexType> </schema> Let's note that element app:restrictedQuantity is in substitution group of sys:quantity. Definition of DerivedType11VALID by restricting BaseType11 forcing it to use app:restrictedQuantity in place of sys:quantity works fine. So far, so good. Deriving from BaseType0u have some singularities, however. Definition of DerivedType0uVALID is valid. But it forces two things at once: using app:restrictedQuantity in place of sys:quantity AND requiring default minOccurs="1" maxOccurs="1". When I want to relax this condition (to force app:restrictedQuantity, but to allow for minOccurs="0" maxOccurs="unbounded" in target schema) it leads to INVALID definition of DerivedType0uINVALID. The only thing I can do while restricting occurence count is with definition of DerivedType12VALID type, where original sys:quantity has to be referred to make this construction valid. So it seems that I can restrict element reference (but forcing its usage) OR restrict usage count (but using original reference). I cannot redefine both. Worse, when I'm restricting element reference, it is not possible even to repeat original relaxed usage count. The error messages are as follows: Description: rcase-RecurseLax.2: There is not a complete functional mapping between the particles. URL: http://www.w3.org/TR/xmlschema-1/#rcase-RecurseLax Description: derivation-ok-restriction.5.4.2: Error for type 'DerivedType0uINVALID'. The particle of the type is not a valid restriction of the particle of the base. URL: http://www.w3.org/TR/xmlschema-1/#derivation-ok-restriction Maybe it is possible to explain using elaborate definitions from http://www.w3.org/TR/xmlschema-1, where I am wrong. But my question tries to be more constructive: - How can I change my definitions to achieve valid desired effect? To anticipate fast responses, I've tried another method. With single sys:quantity element inside BaseType, I can create BaseTypeMod definition modified as follows: <complexType name="BaseTypeMod"> <sequence minOccurs="0" maxOccurs="unbounded"> <element ref="sys:quantity"/> </sequence> </complexType> Now I can redefine both element reference and usage count: <complexType name="DerivedTypeModVALID"> <complexContent> <restriction base="sys:BaseTypeMod"> <sequence minOccurs="1" maxOccurs="2"> <element ref="app:restrictedQuantity"/> </sequence> </restriction> </complexContent> </complexType> Moreover, I can effectively derive even from BaseType0u redefining usage count but on sequence level, not on element level (seems to be strange that I can EXTEND sequence usage when deriving by restriction): <complexType name="DerivedType0uModVALID"> <complexContent> <restriction base="sys:BaseType0u"> <sequence minOccurs="1" maxOccurs="2"> <element ref="app:restrictedQuantity"/> </sequence> </restriction> </complexContent> </complexType> But in real life situations I have more than single element included in definition of complex type. Each of them may have different requirements about its usage count and different rules to be used when deriving. So this construction (placing usage count on sequence level) is of limited usage. So, my questions still remain: - Are there any feasible constructions allowing for effective and flexible derivation by restriction in presented case? - If not, what is wrong: - XML schema stiffness and formality? - my expectations about its usage? Happy New Year anyway! -- View this message in context: http://old.nabble.com/Parallel-deriving-of-components-and-containers-using-derivation-by-restriction---consistency-problem-tp26977566p26977566.html Sent from the w3.org - xmlschema-dev mailing list archive at Nabble.com.
Received on Thursday, 31 December 2009 11:49:48 UTC