Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@a...] Sent: Sat 6/8/2002 2:11 AM To: Dare Obasanjo Cc: xml-dev@l... Subject: RE: 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
|
