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 Friday, 3 November 2000 15:55:43 UTC