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 ]

In cases like this schema authors can use the block attribute to prevent xsi:type assertion from being used in instance documnts. Of course, schema authors first have to be educated on why this is necessary. 
 
Someone should start a series of articles/tutorials designed at making W3C XML Schema more accessible. Or maybe a good book based on real world experiences.

	-----Original Message----- 
	From: Paul Prescod [mailto:paul@prescod.net] 
	Sent: Sat 6/8/2002 12:29 PM 
	To: Henry S. Thompson 
	Cc: Dare Obasanjo; Amelia A Lewis; xml-dev@lists.xml.org 
	Subject: Re: [xml-dev] xsi:type and broken contracts
	
	

	"Henry S. Thompson" wrote:
	>
	>...
	> Um, no, the content model for dl in XHTML is (dt|dd)*, which will
	> cover what your rules produce, and what they produce will look OK
	> too. 
	
	Let's not get hung up on the details of XHTML. There are many content
	models of the form (x,y)+ out there. And anyhow, I can come up with
	these examples all day.
	
	<!ELEMENT DOC (TITLE, P+)>
	
	The processing rules are set up to presume title precedes all paragraphs
	(that's what the schema says, after all). Then someone uses an extension
	to add a TITLE to the end.
	
	<!ELEMENT doc (head, body)>
	
	I have a set of rules like this:
	
	doc ->
	<html><xsl:apply-templates/></html>
	
	head ->
	<head><xsl:apply-templates/></head>
	
	body ->
	<body><xsl:apply-templates/></body>
	
	Then someone uses an extension or xsi:type to change the content model
	to:
	
	<!ELEMENT doc (head, body, body)>
	
	My output will be unexpected. I'm willing to bet that most non-trivial
	stylesheets make assumptions of this sort. That is, after all, the
	reason you have schemas: to make the input data predictable. If some
	random element can appear at the end of a parent element, that random
	element can trigger unexpected processing that was intended for the same
	element in some different context.
	
	Writing stylesheets that are safe in the face of this sort of trick is
	going to be twice as hard as writing ordinary stylesheets. Essentially
	you are "re-enforcing" the ordering constraints from the schema. This
	also makes my stylesheet more fragile because I have to change it in
	lockstep with the input schema.
	
	 Paul Prescod
	





 

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

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