[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: xsi:type and broken contracts

  • To: "Paul Prescod" <paul@p...>,"Henry S. Thompson" <ht@c...>
  • Subject: RE: xsi:type and broken contracts
  • From: "Dare Obasanjo" <dareo@m...>
  • Date: Sat, 8 Jun 2002 12:39:17 -0700
  • Cc: "Amelia A Lewis" <amyzing@t...>,<xml-dev@l...>
  • Thread-index: AcIPItKWrbZf2o5GQ7yyoEERjW9ccgAANTo6
  • Thread-topic: xsi:type and broken contracts

broken contracts
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@p...] 
	Sent: Sat 6/8/2002 12:29 PM 
	To: Henry S. Thompson 
	Cc: Dare Obasanjo; Amelia A Lewis; xml-dev@l... 
	Subject: Re:  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
	


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.