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

RE: xsi:type and broken contracts

• To: "Michael Leditschke" <mike@a...>
• Subject: RE: xsi:type and broken contracts
• From: "Dare Obasanjo" <dareo@m...>
• Date: Fri, 7 Jun 2002 20:09:06 -0700
• Cc: <xml-dev@l...>
• Thread-index: AcIOmD8t93a4sN2pS3Ozp+oZYJ4lEAAAGEGw
• Thread-topic: xsi:type and broken contracts

You can process on the basis of the type of the element. For instance I
can process all myns:Employee elements off type myns:EmployeeType.
However a valid instance can use xsi:type to assert its type to that of
a derived type in another schema which I the original author of the
processing code knows nothing about. 

Similarly I can write C# code that processes instances of
System.Xml.XmlNode which means that I can also process any derived types
regardless of whether I knew about them at the time of writing the code
or not. 

The saving grace which I pointed out and Henry Thompson agreed with is
that derived types cannot radically alter the content model due to how
restriction and extension work. So even though elements that assert
their types as foo:MicrosoftEmployee, bar:GovernmentEmployee, etc show
up in the instance document when I expected myns:EmployeeType types, my
code should still be able to handle them since they are derived types
and will have similar structure and content. 

PS: CCing XML-DEV since this is relevant discussion that could do with
public consumption. 

-- 
PITHY WORDS OF WISDOM 
The shortest distance between two points is under repair.

This posting is provided "AS IS" with no warranties, and confers no
rights. 


> -----Original Message-----
> From: Michael Leditschke [mailto:mike@a...] 
> Sent: Friday, June 07, 2002 7:58 PM
> To: Dare Obasanjo
> Subject: RE:  xsi:type and broken contracts
> 
> 
> Hi Dare. 
> 
> There's something I don't quite understand in this scenario. 
> I wondered if you would mind helping?
> 
> To process on the basis of xsi:type don't you need access to 
> the schema, 
> in which case the set of allowable values for xsi:type is known? 
> 
> To extend in the instance (and still be valid), the schema 
> and hence the contract with the processing code changes. 
> 
> Do you envisage code doing this processing without reference to 
> the schema? If so, how will it know the definition of any type, 
> unless this is hardcoded? Or are you envisaging the situation 
> where the schema gets ahead of the code?
> 
> Regards
> Michael
> 
> > With XQuery and XSLT one can attempt to process elements based on 
> > their XSD types but with xsi:type one can both restrict and extend 
> > these types in the instance document unbeknownst to the 
> author of the 
> > processing code. At first glance it seems like both these 
> mechanisms 
> > do not radically alter the content model in such a manner that 
> > carefully written type aware processors will be rendered 
> ineffective.
> > 
> > However until applications start getting built there probably is no 
> > sure way to tell if my fears are unfounded or not.
> 
> 
> 

• Follow-Ups:
  • RE: xsi:type and broken contracts
    • From: "Michael Leditschke" <mike@a...>

• Prev by Date: RE: Interesting mailing list & a rare broadside
• Next by Date: RE: Interesting mailing list & a rare broadside
• Previous by thread: Re: xsi:type and broken contracts
• Next by thread: RE: xsi:type and broken contracts
• Index(es):
  • Date
  • Thread