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 ]

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

OK. Its a valid instance, which implies its got a PSVI that's been built
from a schema that references the type the code knows "nothing" about. Yes?

So your code is something like a library, being used as part of a system 
designed by someone else, who has extended the original schema you
designed for to include new types as you suggest below? 


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

Understood. If restriction, you should already handle the more open
constraints of the myns:EmployeeType; if extension, you'll ignore the 
extra stuff.


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

As you wish.

Regards
Michael





 

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

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