[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: Sat, 8 Jun 2002 03:47:15 -0700
• Cc: <xml-dev@l...>
• Thread-index: AcIOzG+TcI2m1ShDQj2MSS1gxMzE9wADQS/6
• Thread-topic: 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@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
	
	

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

• Prev by Date: Re: Malicious documents? (WAS: Interesting mailing list & a rare broadside)
• Next by Date: Re: Constitutionally incapable (was Re: W3C Schema: Resistance is Futile, says Don Box)
• Previous by thread: RE: xsi:type and broken contracts
• Next by thread: RE: xsi:type and broken contracts
• Index(es):
  • Date
  • Thread