OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] xsi:type and broken contracts

[ 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

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

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";

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";

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"/>

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

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

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).



Jeni Tennison


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS