- From: Kevin Braun <kbraun@obj-sys.com>
- Date: Thu, 03 Dec 2009 14:00:20 -0500
- 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