[
Lists Home |
Date Index |
Thread Index
]
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/
|
