[
Lists Home |
Date Index |
Thread Index
]
- To: "Michael Leditschke" <mike@ammd.com.au>
- Subject: RE: [xml-dev] xsi:type and broken contracts
- From: "Dare Obasanjo" <dareo@microsoft.com>
- Date: Sat, 8 Jun 2002 03:47:15 -0700
- Cc: <xml-dev@lists.xml.org>
- Thread-index: AcIOzG+TcI2m1ShDQj2MSS1gxMzE9wADQS/6
- Thread-topic: [xml-dev] xsi:type and broken contracts
The code doesn't have to be part of a library, it could just be code that manipulates documents coming in from external sources. The fact is that the combination of xsi:schemaLocation and xsi:type make it very likely that a type aware application will come across derived types in instance documents unless these attributes are specifically mandated against.
-----Original Message-----
From: Michael Leditschke [mailto:mike@ammd.com.au]
Sent: Sat 6/8/2002 2:11 AM
To: Dare Obasanjo
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] 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.
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
|