XML Editor
Sign up for a WebBoard account Sign Up Keyword Search Search More Options... Options
Chat Rooms Chat Help Help News News Log in to WebBoard Log in Not Logged in
Show tree view Topic
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Postnext
Robert LeifSubject: ComplexType Inheritance
Author: Robert Leif
Date: 27 Aug 2006 06:16 PM
Bob Leif
I am working on a collection of schemas, CytometryML, which includes scientific units. These schemas are based on the Digital Imaging and Communications in Medicine (DICOM Standard). I start with a "Scientific_Unit_Type", specialize it to a Meter_Type, and finally specialize it to an X_Offset_Type. This specialization is by restriction.

This works provided that I do it all in one schema (units_test). However, when I put the X_Offset_Type in its own schema (coords.xsd), I receive the following error message, "Validating coords.xsd...
file:///g:/CytometryML/Schemas/coords.xsd:17,55: Recurse: There is not a complete functional mapping between the particles
The XML document coords.xsd is NOT valid (1 errors)". It would help if the error message stated explicitly what did not match. I am grateful for any suggestions.

Thank you.
Bob Leif


Unknownunits_test.xsd
First schema which works by itself

Unknowncoords.xsd
2nd schema which imports the first

Postnext
Alberto MassariSubject: ComplexType Inheritance
Author: Alberto Massari
Date: 28 Aug 2006 08:10 AM
Hi Bob,
the problem lies in the fact that the two schemas have different target namespaces; this way the test:X_Offset_Type inside units_test.xsd ends up having a child test:Value, test:Prefix_Name, test:Prefix_Case_Sen, test:Si_Unit_Name, test:Unit_Abbreviation (because the elementFormDefault attribute is 'qualified', all local element definitions are placed in the target namespace), while the coords:X_Offset_Type in coords.xsd ends up having a child coords:Value, coords:Prefix_Name, coords:Prefix_Case_Sen, coords:Si_Unit_Name, coords:Unit_Abbreviation.
The two elements have the same structure and same local name, but different namespaces, and this is not allowed in a restriction.
In order for them to have the same namespace, you must change the type to use references to global types, e.g. create a

<element name="Value" type="test:Offset_Value_Type"/>

in the units_test.xsd file and replace its definition inside the X_Offset_Type with a reference

<element ref="test:Value"/>

Hope this helps,
Alberto

Postnext
Robert LeifSubject: ComplexType Inheritance
Author: Robert Leif
Date: 28 Aug 2006 08:56 PM
Bob Leif

Hi Alberto
I have made extensive tests and found that I could validate under XMLSpy, when I declared my elements in coords to be unqualified. This did not work with StylusStudio. XMLSpy failed with the original version of my code, which includes many more schemas with complex dependencies.

Since in object oriented programming, the parent schema should not know the content of the child schema, I should not define an element in the parent schema for use as a reference in the child schema. However, I did try it and it also failed. I substituted
<element ref="test:Float64"/> for
<element name="Value" type="test:Offset_Value_Type"/>
The error message was:
"Validating coords.xsd...
file:///g:/CytometryML/Schemas/coords.xsd:18,40: Recurse: There is not a complete functional mapping between the particles
The XML document coords.xsd is NOT valid (1 errors)"

According to XML Schema Part 1: Structures Second Edition
W3C Recommendation 28 October 2004
"2.2.1.1 Type Definition Hierarchy
[Definition:] Except for a distinguished •ur-type definition•, every •type definition• is, by construction, either a •restriction• or an •extension• of some other type definition. The graph of these relationships forms a tree known as the Type Definition Hierarchy.
[Definition:] A type definition whose declarations or facets are in a one-to-one relation with those of another specified type definition, with each in turn restricting the possibilities of the one it corresponds to, is said to be a restriction. The specific restrictions might include narrowed ranges or reduced alternatives. Members of a type, A, whose definition is a •restriction• of the definition of another type, B, are always members of type B as well."

This definition does not say anything about namespaces. It is obvious that two type in different namespaces with the same name should not be considered to be the identical. However, since a type can be derived by restriction from a type in another namespace, I would think that the Type Definition Hierarchy would not be changed by restrictions across namespaces. I should note that in the attached examples all of the elements in the complexType, Slide_Offset_Type, have test as their prefix and the schema still will not validate.

Possibly, the least bad solution is to put all of the unit used in CytometryML in a very large schema and give up on specifying the ranges of the children of test:Value_Type. However, this would significantly diminish the reliability of any XML pages or XForms that are validated by the CytometryML schemas.
Thank you.
Bob Leif


Unknownunits_test(1).xsd
Parent schema

Unknowncoords(1).xsd
Child Schema

Postnext
Alberto MassariSubject: ComplexType Inheritance
Author: Alberto Massari
Date: 29 Aug 2006 11:59 AM
Hi Bob,

>I have made extensive tests and found that I could
>validate under XMLSpy, when I declared my elements in coords
>to be unqualified. This did not work with StylusStudio.

That's strange, because I can validate your schemas (after replacing the <element ref="test:Float64"/> with a <element name="Value" type="test:Float64_Type"/> or even a <element name="Value" type="coords:Offset_Value_Type"/>)

>Since in object oriented programming, the parent schema
>should not know the contet of the child schema, I should not
>define an element in the parent schema for use as a
>reference in the child schema.

You are making the assumption that XMLSchema is an object oriented programming language, but it isn't; it doesn't have the notion of encapsulation, but it can only add to a base type new elements/attributes, or restrict the range of allowed values
So, the derived type must know the components of the base type, preserve the same names used in that type, and just change some parts of it.

>However, I did try it and it also failed. I substituted
><element ref="test:Float64"/> for
><element name="Value" type="test:Offset_Value_Type"/
>>
>The error message was:
>"Validating coords.xsd... file:///g:/CytometryML/Schemas/coords.xsd:18,40: Recurse:
>There is not a complete functional mapping between the
>particles

The error occurs because in your schema you have a Scientific_Unit_Type base type that has a subelement named "Value" of type "test:Float64_Type", but in your restricted type Slide_Offset_Type you have placed the the reference to test:Float64; and Value doesn't match Float64. As I have already said in the first answer, you don't need to use the reference to test:Float64 and can safely use Value also in the derived type; but if you go that route, you must use the reference to test:Float64 also in the base type.

>According to XML Schema Part 1: Structures Second Edition
>W3C Recommendation 28 October 2004
>"2.2.1.1 Type Definition Hierarchy
>[Definition:] Except for a distinguished •ur-type definition•, every •type definition• is, by construction, either a •restriction• or an •extension• of some other type definition. The graph of these relationships forms a tree known as the Type Definition Hierarchy.
>[Definition:] A type definition whose declarations or facets are in a one-to-one relation with those of another specified type definition, with each in turn restricting the possibilities of the one it corresponds to, is said to be a restriction. The specific restrictions might include narrowed ranges or reduced alternatives. Members of a type, A, whose definition is a •restriction• of the definition of another type, B, are always members of type B as well."
>
>This definition does not say anything about namespaces. It is obvious
>that two type in different namespaces with the same name should not be
>considered to be the identical. However, since a type can be derived by
>restriction from a type in another namespace, I would think that the
>Type Definition Hierarchy would not be changed by restrictions across
>namespaces. I should note that in the attached examples all of the
>elements in the complexType, Slide_Offset_Type, have test as their
>prefix and the schema still will not validate.

I don't understand your point; here the problem is not that a type hierarchy can mix types from different namespace (type coords:Unit can derive from tests:BaseUnit that derives from yet another myNS:RootType - just think that all the base types all reside in the XMLSchema namespace). The problem is that, when deriving by restriction, you must re-declare the entire base type definition with some changes in its minOccurs/maxOccurs/fixed/default/etc.. facets (if needed). But doing this in a different targetNamespace will declare them with a different name, and that's not allowed.

>Possibly, the least bad solution is to put all of the
>unit used in CytometryML in a very large schema and give up
>on specifying the ranges of the children of
>test:Value_Type. However, this would significantly diminish
>the reliability of any XML pages or XForms that are
>validated by the CytometryML schemas.

I don't know the type hierarchy you have in mind; I can only suggest to do a research for how other schemas have workarounded the limitations of the XMLSchema language to achieve a multi-namespaces type hierarchy.

Hope this helps,
Alberto

Postnext
Robert LeifSubject: ComplexType Inheritance
Author: Robert Leif
Date: 30 Aug 2006 08:38 PM
Bob Leif
Hi Alberto,
Many thanks for your advice. I was surprised that restriction is effectively not permitted when a child schema imports a parent schema. However, I was able to circumvent this problem by restructuring my inheritance by using an extension element, which did validate. In order to simplify the situation, I used the xsdl primitive type double for the Value element <element name="Value" type="double"/> the complexType, Meter_Type, both my parent schema (units_test) and my child schema (coords). Unfortunately, when I tried to restrict it, even in the parent schema (units_test), I received an error message:
Validating units_test.xsd...
file:///g:/CytometryML/Schemas/units_test.xsd:330,55: Recurse: There is not a complete functional mapping between the particles

The XML document units_test.xsd is NOT valid (1 errors)


Unknownunits_test(2).xsd
Parent schema with error

Unknowncoords(2).xsd
Child Schema with similar error

Posttop
Alberto MassariSubject: ComplexType Inheritance
Author: Alberto Massari
Date: 31 Aug 2006 04:03 AM
Hi Bob,
the error in the units_test.xsd is due to the fact that deriving by extension must not specify the components of the base type, that are automatically placed at the beginning of the new type.
So, in your case, Meter_Type should be declared as

<extension base="test:Scientific_Unit_Extensible_Type">
<sequence>
<element name="Value" type="double"/>
</sequence>
<attribute name="Tag" type="test:Tag_Type" use="optional"/>
<attribute name="VR" type="test:VR_Type" use="optional"/>
</extension>

and the X_Offset_Type should place the restricted Value element at the end of the declaration

<restriction base="test:Meter_Type">
<sequence>
<choice>
<element name="Prefix_Name" type="test:Prefix_Name_Type" fixed="milli"/>
<element name="Prefix_Case_Sen" type="test:Case_Sen_Type" fixed="m"/>
</choice>
<choice>
<element name="Si_Unit_Name" type="test:Si_Unit_Name_Type" fixed="meter"/>
<element name="Unit_Abbreviation" type="test:Unit_Abbreviations_Type" fixed="m"/>
</choice>
<element name="Value" type="double"/>
</sequence>
<attribute name="Tag" type="test:Tag_Type" fixed="0040,072A"/>
<attribute name="VR" type="test:VR_Type" fixed="DS"/>
</restriction>

The same changes should be applied to the Slide_Offset_Type in the coords.xsd; furthermore, the Slide_Offset_Type should be split into two complex types, one restricting the values for the inherited Prefix_Name/Prefix_Case_Sen/Si_Unit_Name/Unit_Abbreviation element, and one extending that one to add the Value element.
But you will be back to old issue, because you will not be able to refer to the proper test:Prefix_Name nome from within coords.xsd....

Another point that should be examined is the final result of a schema designed in this way (the fact that you define complex types in a namespace and reuse from another namespace): that is, how will an XML instance will look.

<coords:slide xmlns:coords="http://CytometryML/Schemas/coords" xmlns:test="http://CytometryML/Schemas/units_test">
<test:Prefix_Name>milli</test:Prefix_Name>
<test:Si_Unit_Name>meter</test:Si_Unit_Name>
<coords:Value>10</coords:Value>
</coords:slide>

You will have a mix of namespaces that will need to be carefully intermixed; if you go for the first option I proposed (having global element declarations in the unit_tests namespace, referenced by the derived types in both namespaces) you will have this XML

<coords:slide xmlns:coords="http://CytometryML/Schemas/coords" xmlns:test="http://CytometryML/Schemas/units_test">
<test:Value>10</test:Value>
<test:Prefix_Name>milli</test:Prefix_Name>
<test:Si_Unit_Name>meter</test:Si_Unit_Name>
</coords:slide>

where the namespaces are still (slightly less) intermixed.
The third option, using 'unqualified' as the element form default, will lead to this XML

<coords:slide xmlns:coords="http://CytometryML/Schemas/coords">
<Value>10</Value>
<Prefix_Name>milli</Prefix_Name>
<Si_Unit_Name>meter</Si_Unit_Name>
</coords:slide>

where the inner components needs not to have a namespace prefix (and, if a default namespace has been specified, the 'slide' element needs an extra xmlns="" declaration that is only available in XML 1.1)

I cannot advise you on the structure of the schema you are designing, as I ignore the constraints you must satisfy, but I just wanted to let you know the consequences of split schema design.

Hope this helps,
Alberto

 
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Download A Free Trial of Stylus Studio 6 XML Professional Edition Today! Powered by Stylus Studio, the world's leading XML IDE for XML, XSLT, XQuery, XML Schema, DTD, XPath, WSDL, XHTML, SQL/XML, and XML Mapping!  
go

Log In Options

Site Map | Privacy Policy | Terms of Use | Trademarks
Stylus Scoop XML Newsletter:
W3C Member
Stylus Studio® and DataDirect XQuery ™are from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2016 All Rights Reserved.