[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: xsi:type and broken contracts
Hi Amelia, > I hope that my understanding is incorrect, and someone can point out > that one or more of the following are true (or that there is some > other saving grace somewhere in the system): > > 1) xsi:type must always be a "narrowing cast" > 2) xsi:type cannot replace a complex type with a simple one > 3) xsi:type overrides can be disabled in the parser See Clause 4.3 of Validation Rule: Element Locally Valid (Element) at http://www.w3.org/TR/xmlschema-1/#cvc-elt, which says: The ·local type definition· must be validly derived from the {type definition} given the union of the {disallowed substitutions} and the {type definition}'s {prohibited substitutions}, as defined in Type Derivation OK (Complex) (§3.4.6) (if it is a complex type definition), or given {disallowed substitutions} as defined in Type Derivation OK (Simple) (§3.14.6) (if it is a simple type definition). In other words, the type named by xsi:type must always be derived from the type declared for the element. Whether you could that as 'narrowing' or not depends on what you mean by 'narrowing'. If you go to the linked Type Derivation OK Schema Component Constraints, you'll see that: - if the declared type of the element is a complex type, then the type named by xsi:type must be derived by extension or restriction from that type - if the declared type of the element is a simple type, then the type named by xsi:type must be derived by restriction from that type, or be one of the member types if the element's type is a union So (2) is certainly true. I don't think that you can prevent xsi:type being used within a schema validator, but you certainly can within the schema. As in the above, the values of the {disallowed substitutions} of the element and {prohibited substitutions} of the element's type (block/blockDefault attribute) have a big effect over whether xsi:type can be used or not. If you want to prevent a document validated against your schema from using xsi:type, you can do: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" blockDefault="#all"> ... </xs:schema> I think that your concept of 'narrowing' probably equates to the XML Schema of 'restriction', so if you want to permit xsi:type to be used, but only when it 'narrows' the definition, you could use: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" blockDefault="extension"> ... </xs:schema> If you want to declare an element with a date/time type (of any kind), and allow that to be restricted to something else, then you can use a union type: <xs:simpleType name="anyDateOrTime"> <xs:union memberTypes="xs:dateTime xs:date xs:time xs:gYear xs:gMonth xs:gDay xs:gYearMonth xs:gMonthDay"/> </xs:simpleType> and declare your element as being of that type. Individual elements can then declare themselves as being of a particular date/time type using xsi:type if they want (although since there's no clash in lexical representation between the types, it's not strictly necessary). You can do a similar thing to combine xs:QName, xs:anyURI and xs:string if you want, though you should probably list them in that order since their lexical representations do overlap, or make the union type abstract so that instances are forced to always use xsi:type. I agree that xsi:type can open up unexpected holes in the validation of a document -- I think most xs:schema elements should probably have a blockDefault attribute on them to explicitly close them (a bit like most should have an elementFormDefault attribute on them to ensure that locally-declared elements are in the target namespace). Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|