[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: xsi:type and broken contracts

• To: amyzing@t... (Amelia A Lewis)
• Subject: Re: xsi:type and broken contracts
• From: ht@c... (Henry S. Thompson)
• Date: 07 Jun 2002 21:59:51 +0100
• Cc: xml-dev@l...
• In-reply-to: <20020607165415.GA28653@t...>
• References: <20020607165415.GA28653@t...>
• User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2(beta13) (Demeter)

amyzing@t... (Amelia A Lewis) writes:

> xsi:type is a scab.
> 
> If the union of instances agrees to a contract (the schema) with management
> (the parser), xsi:type is the badge of the scab.
> 
> For example, suppose that a system is designed such that a few thousand
> licensed franchisees are going to collect some information, which they are
> going to submit (over secured, authenticated links) to a battery of one
> hundred validating servers, which in turn all feed into a single process
> server.  The idea is to offload validation from the main processing server,
> but still have control over the input, to guarantee its correctness.
> 
> Imagine, then, that a portion of the schema which is to be used for
> submission looks like this:
> 
> <xs:element name="registrant" minOccurs="1" maxOccurs="1">
>   <xs:complexContent>
>     <xs:sequence>
>       <xs:element name="personalName" type="xs:string" minOccurs="1"
>         maxOccurs="1" minLength="2" />
>       <xs:element name="familyName" type="xs:string" minOccurs="1"
>         maxOccurs="1" minLength="2" />
>       <!-- more information here, also very strongly typed -->
>     </xs:sequence>
>   </xs:complexContent>
> </xs:element>

<snip/>

> And here's an excerpt from a valid instance:

An invalid instance, see below.

> <registrant xsi:type="xs:string">No information provided</registrant>
> 
> 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"

False -- it can extend by adding more, but cannot remove required parts.

> 2) xsi:type cannot replace a complex type with a simple one

False, but only if the complex type is 'mixed' and _all_ its element
content is optional.

> 3) xsi:type overrides can be disabled in the parser

False.

> But I don't think that they are true, which means that validation is
> effectively worthless, because no matter how complex the schema created, I
> can always replace it with:
> 
> <rootElement xsi:type="xs:string">Neener, neener!  Look, ma, I'm
> valid!</rootElement>

Invalid, see above

Hope this helps.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2002, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@c...
		     URL: http://www.ltg.ed.ac.uk/~ht/
 [mail really from me _always_ has this .sig -- mail without it is forged spam]

• References:
  • xsi:type and broken contracts
    • From: amyzing@t... (Amelia A Lewis)

• Prev by Date: Evangelizing RNG
• Next by Date: Re: xsi:type and broken contracts
• Previous by thread: Re: xsi:type and broken contracts
• Next by thread: RE: xsi:type and broken contracts
• Index(es):
  • Date
  • Thread