W3C home > Mailing lists > Public > xmlschema-dev@w3.org > December 2009

Re: Why xsi:type works only inwards, not outwards?

From: Kevin Braun <kbraun@obj-sys.com>
Date: Thu, 03 Dec 2009 14:00:20 -0500
Message-ID: <4B180AC4.4020202@obj-sys.com>
To: Krzysztof FF <Krzysztof.Finowicki@tessel.pl>
CC: xmlschema-dev@w3.org
Hi,

One brief comment embedded below.

Kevin

On 12/3/2009 11:13 AM, Krzysztof FF wrote:
> Hi all,
>
> I'm trying to define two-level layered schema - one with generic "system"
> model, second with specific "application" model.
>
> When trying to expose application data using generic system model elements
> specified by using xsi:type attribute referring to application model types,
> I've encountered some asymetry in treating it while validating data.
>
> My example is somehow simplified so as to reflect the issue from topic.
>
> Let's start with system 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="Entity" type="sys:EntityType"/>
>     <complexType name="EntityType">
>         <sequence minOccurs="0" maxOccurs="unbounded">
>             <element ref="sys:category"/>
>         </sequence>
>     </complexType>
>
>     <element name="category" type="sys:CategoryType"/>
>     <simpleType name="CategoryType">
>         <restriction base="string"/>
>     </simpleType>
>     
> </schema>
>
> Now I want to define specific rules for Room derived from Entity by
> restriction in app.xsd:
>
> <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="Room" type="app:RoomType" substitutionGroup="sys:Entity"
> />
>     <complexType name="RoomType">
>         <complexContent>
>             <restriction base="sys:EntityType">
>                 <sequence>
>                     <element ref="app:roomCategory"></element>
>                 </sequence>
>             </restriction>
>         </complexContent>
>     </complexType>
>
>     <element name="roomCategory" type="app:RoomCategoryType"
> substitutionGroup="sys:category"/>
>     <simpleType name="RoomCategoryType">
>         <restriction base="sys:CategoryType">
>             <enumeration value="living"></enumeration>
>             <enumeration value="bedroom"></enumeration>
>             <enumeration value="kitchen"></enumeration>
>         </restriction>
>     </simpleType>
>     
> </schema>
>
> Now I can write data using application model:
>
> <Room>
> <!-- namespaces omitted for brevity -->
>     <roomCategory>living</roomCategory>
> </Room>
>
> I could write the same data using plain system model, because Room is
> derived from Entity by restriction:
>
> <sys:Entity>
> <!-- namespaces omitted for brevity -->
>     <sys:category>living</sys:category>
> </sys:Entity1>
>
> The reason for flattening data to system model is to make it understandable
> for some low-level processing, whatever it is (i.e. without exact knowledge
> on application specifics).
>
> But there are some drawbacks:
> - validation can be made only against system schema, not application schema;
> - information about actual application types has been stripped out, although
> it could be of later use for some high-level processing, whatever it is
> (i.e. using knowledge of aplication specifics).
>
> My natural attempt was to use xsi:type attribute.
>
> But it occured that I can write 
>
> <sys:Entity xsi:type="RoomType">
> <!-- namespaces omitted for brevity -->
>     <roomCategory>living</roomCategory>
> </sys:Entity1>
>
> OR
>
> <sys:Entity>
> <!-- namespaces omitted for brevity -->
>     <sys:category xsi:type=RoomCategoryType">living</sys:category>
> </sys:Entity>
>
> BUT USING xsi:type on both levels is illegal:
>
> <sys:Entity xsi:type="RoomType">
> <!-- namespaces omitted for brevity -->
>     <sys:category xsi:type=RoomCategoryType">living</sys:category>
> </sys:Entity1>
>
>   
I believe this would be invalid because you have indicated that 
sys:Entity is actually a "RoomType", but then you give a sys:category 
for the child, which is not legal according to "RoomType" - you need an 
"app:roomCategory" element.  Once you tell it the type the element 
should be validated against, you have to follow the model for that type.
> It seems that xsi:type "works" inwards, forcing inner content of element to
> be validated along referred type. But in the same time, it does not work
> outwards, i.e. inner element is not exposed as referred type - element name
> is interpreted explicitly instead.
>
> This is what I assume some drawback in how XML schema works, and causes my
> concept for exposing data using layered schemas to be illegal.
>
> I wonder if somebody could explain if there are some valid reasons for
> hiding xsi:type attribute referred from inner elements to their parent
> elements.
>
>
>
>   
Kevin Braun
-- 
Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com
Received on Thursday, 3 December 2009 19:03:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:17 UTC