RE: (Summary) Implementation Experience: INCORRECT usage of xsi:type in Union Types

[1] This feature is based on some complex and underspecified rules (sorry,
readers can't parse these rules) as specified in Part 1,
http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/#cos-st-derived-ok

[2] In addition, this feature is based on a myth, "a member of the defined
union type is a valid restriction of the defined union type". The truth is
that such a derived type can

- neither be expressed using XML Schema Surface Syntax
- nor be expressed using XML Schema Components

[3] On June 26th, 2000, one of the special task force teams presented IG
with a proposal for "Adding simple type definitions by union to XML Schema"

http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2000Jun/att-0330/01-un
ion-design.html

But, this proposal does not say anything about the current usage of xsi:type
in union types. Hence, WG was not aware of this when it decided to accept
it. This is a badly formed feature that parachuted into the spec.

Proposed Resolutions,

[Option 1] Remove xsi:type override from Union Type Definition
[Option 2] Specify the rules for xsi:type override CLEARLY in Part 1;
provide numerous examples; primer should provide sufficient examples to
educate schema authors; provide a mechanism to express 'a member of the
defined union type is a valid restriction of the defined union type' using
surface syntax and components

My preference: for simplicity, I invoke 80/20 rule .., option 1

Regards, Asir S Vedamuthu
-----Original Message-----
From: www-xml-schema-comments-request@w3.org
[mailto:www-xml-schema-comments-request@w3.org]On Behalf Of Biron,Paul V
Sent: Friday, November 03, 2000 3:34 PM
To: 'Www-Xml-Schema-Comments@W3. Org'
Cc: 'W3c-Xml-Schema-Ig'; 'Ningang chen'
Subject: RE: Implementation Experience: INCORRECT usage of xsi:type in
Union Types


> -----Original Message-----
> From:	ht@cogsci.ed.ac.uk [SMTP:ht@cogsci.ed.ac.uk]
> Sent:	Friday, November 03, 2000 10:37 AM
> To:	asirv@webmethods.com
> Cc:	Www-Xml-Schema-Comments@W3. Org; W3c-Xml-Schema-Ig; Ningang chen
> Subject:	Re: Implementation Experience: INCORRECT usage of xsi:type
> in Union Types
>
> "Asir S Vedamuthu" <asirv@webmethods.com> writes:
>
> > <xsd:element name='size'>
> >   <xsd:simpleType>
> >     <xsd:union>
> >     <xsd:simpleType>
> >       <xsd:restriction base='xsd:integer'/>
> >     </xsd:simpleType>
> >     <xsd:simpleType>
> >       <xsd:restriction base='xsd:string'>
> > 	  <xsd:enumeration value='5'/>
> > 	  <xsd:enumeration value='6'/>
> > 	</xsd:restriction>
> >     </xsd:simpleType>
> >   </xsd:union>
> >  </xsd:simpleType>
> > </xsd:element>
> >
> > <size xsi:type='xsd:string'>1</size>
> >
> > In the above example, 'xsd:string' one of the primitive built-in type is
> NOT
> > VALIDLY DERIVED from the defined union type. Defined union type contains
> two
> > anonymous types. Instance can never NEVER identify one of the members
> using
> > a QName.
>
> Correct.  What is the implementation problem -- note an error and move
> on.
>
As I pointed out in my previous message, it's not even an error...there is a
specific clause in the relevant constraint in structures to account for
union types.

> > <xsd:element name='size'>
> >   <xsd:simpleType>
> >     <xsd:union memberTypes='xsd:integer xsd:string'>
> > 	<xsd:pattern value='1'/>
> > 	<xsd:pattern value='(1|2)'/>
> > 	<xsd:pattern value='(small|medium|large)'/>
> >     </xsd:union>
> >   </xsd:simpleType>
> > </xsd:element>
> >
> > <size xsi:type='xsd:string'>small</size>
> >
> > In the above example, 'xsd:string' one of the primitive built-in type is
> NOT
> > VALIDLY DERIVED from the defined union type. Defined union type contains
> two
> > named built-in types. However the lexical space of the newly defined
> type is
> > constrained by the patterns.
>
> I'm not sure what you're getting at here.  Stipulate that the
> declaration above is corrected syntactically to
>
> <xsd:element name='size'>
>  <xsd:simpleType>
>   <xsd:restriction>
>    <xsd:simpleType>
>      <xsd:union memberTypes='xsd:integer xsd:string'/>
>    </xsd:simpleType>
>    <xsd:pattern value='1'/>
>    <xsd:pattern value='(1|2)'/>
>    <xsd:pattern value='(small|medium|large)'/>
>   </xsd:restriction>
>  </xsd:simpleType>
> </xsd:element>
>
> <size xsi:type='xsd:string'>small</size>
>
> Two things:
>
>  1) Your type is empty, I think -- that is, because multiple patterns
>     are conjoined, you require something impossible to satisfy.
>
No, the type is not empty...as stated in [1]

	If multiple pattern element information items appear as
	[children] of a simpleType, the [value]s should be combined
	as if they appeared in a single regular expression as separate
	branches.

That is, at the XML Representation level, multple occurances of the pattern
facet are treated analogously to multiple occurances of the enumeration
facet...instances must match any one of them, i.e., they are "disjoined".

In otherwords, those three xsd:pattern elements could have been specified in
a single element:

	<xsd:pattern value='1|2|small|medium|large'/>

However, when a type that has a value for the pattern facet (at the
component level, there will only be one) and that type is restricted by
specifying (at least) another pattern facet, then the effective value for
the pattern facet (at the component level) of the new derived type is the
conjunction of the pattern facet in the base type and the patten facet
specified in the restriction.

>  2) Leaving that aside, according to the CR draft, the instance is
>  valid: 'small' is certainly a string, and 'xsd:string' can appear
>  because clause 1.2.2.4 of [1] says xsd:string (D) is validly derived
>  from union(xsd:string, xsd:integer) (B) if:
>
>      "1.2.2.4 B's {variety} is union and D is validly derived from a
>      type definition in B's {member type definitions} given the
>      subset, as defined by this constraint.
>
>   So the CR draft says this instance is OK.  I'm not sure whether this
> is a catastrophe or not, but if we think it is, the fix is obvious:
> amend 1.2.2.4 to either
>    a) require that the union (B) have no constraining facets of its own;
>    b) require that the candidate (D) have facets at least as
>       constraining as the union (B)
> I'm not sure which I'd prefer.
>
I do NOT think it is a catastrophe because that is the required and expected
behavior: it should be OK.

Now, suppose the instance said:

	<size xsi:type='xsd:stirng'>some value not matched by the
pattern</size>

If this instance were considered OK then that would be a catastrophe, but I
don't think it is.  That is, just because "some value not matched by the
pattern" is a valid xsd:string it shouldn't validate (because it doesn't
match the pattern facet).

pvb

References
[1] http://www.w3.org/TR/xmlschema-2.html#src-multiple-patterns

Received on Monday, 11 December 2000 08:37:23 UTC