I was once asked by one user who was unable to restrict complex type in XML schema definition (XSD) while using ISO 21090 data type.
Below is the simple use case, first the user defined a generic complex type - GenericElement, the value element uses ISO21090 "ANY" data type. The Element type then was used in defining the "ProcedureElement" type, and the user intended to tighten the XSD definition to use "CD" data type for "value" element as shown in below figure
However the XSD is invalid,It looks fine at first glance, ANY data type is the generic one, CD data type is extended from ANY. The reported error message in XMLSpy is as following
Details
rcase-NameAndTypeOK.3.2.5: Type definition 'CD' (element 'value') is not validly derived given {extension, list, union} from type definition 'xs:anyType' (element 'value').
rcase-NameAndTypeOK.1: The declarations' {name}s and {target namespace}s are not the same: restriction element is and base element is .
rcase-Recurse.2.1: This must restrict the corresponding of the base content model.
derivation-ok-restriction.5.4: The content type is not a valid restriction of content type .
It turns out that tt violates the XSD restriction rule as defined here - Schema Component Constraint: Derivation Valid (Restriction, Complex), specifically the following two rules
4.3 Unless the {base type definition} is the ·ur-type definition·, the complex type definition's {attribute wildcard}'s {process contents} must be identical to or stronger than the {base type definition}'s {attribute wildcard}'s {process contents}, where strict is stronger than lax is stronger than skip.
5.1 The {base type definition} must be the ·ur-type definition·.
So the problem is that 1) the "ANY" data type used in the GenericElement definition is not ·ur-type definition· , 2) "CD" data type definition is not directly extended from ·ur-type definition·, "CD" is not restricted from "ANY" data type
In order to fix the problem, we can make make the following changes in the XSD
1) Change the "value" element's type to "xs:anyType"
2) Define a new CD data type directly - named as "CodedData" in this example, and use this new CD data type to tighten the value element type.
Below is a sample fix to use xsd restriction
so what's the lesson learned here?
1) When using ISO21090 data type, be aware of XSD limitation. This is also one of the reason we need to decouple object model vs. exchange model, anyway ISO21090 data type is abstract data type, so we probably need to have two concrete implementations - one for information modeling, and other for wire format
2) try not to use XSD restrict feature in XSD definition if possible, use XSD extension as much as you can. The other underlying reason is that OO does not support restriction, so if you are going to generate java object from XSD, all these restriction will be lost in the generated objects.
Subscribe to:
Post Comments (Atom)
Public Sector Day Singapore 2024
I was delighted to be invited by AWS to share how we designed and implemented robust tech foundation for Singapore Healthier SG and Age Well...
-
Below is the some of the slides from the recent sharing at FHIR DevDays 2024 ( https://www.devdays.com/ ) on Singapore's National Healt...
-
During recent Ken Rubin's trip to Singapore in May 28, I shared my views and suggestions on how to effectively adopt/develop healthcare...
-
I am involved in HL7 Singapore technical committee, during one of the discussions about the topic for technical sharing, we discussed within...
No comments:
Post a Comment