OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: On Schemas, Namespaces and Syntax vs. Semantics (long but worth it)

[ Lists Home | Date Index | Thread Index ]

I once sat through a presentation where someone pointed out that the worst security flaws typically are caused by situtions where code [or objects/components] is reused outside of its original purpose or design guidelines. Trying to make technology that is immune to incompetence is a loosing battle because the Universe is one step ahead of you creating the one person who will outwit your fool-proof design. The fact that your attempts at foolproofing involve W3C XML Schema already assures me they aren't. As for your responses
 
a.) The only difference between using attributes from a special processing namespace and PIs is that the attributes can be validated while the PIs cannot. Everything else you mentioned is a red herring. 
 
b.) Given the complexity of W3C XML Schema and the lack of interoperability between implementations, I tend to avoid solutions that involve having people author more schemas than they have to. 
 
c.) Here's one attempt to provide a schema for the no-brainer approach of wrapping the customer data in an element with semantic meaning 
 
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; 
          xmlns:cust="urn:xmlns:25hoursaday-com:customer" 
          targetNamespace="urn:xmlns:25hoursaday-com:customer" 
   elementFormDefault="qualified"> 
        
<xs:complexType name="CustomerActionBase" abstract="true">
  <xs:sequence>
   <xs:element ref="cust:Customer" maxOccurs="unbounded" />
  </xs:sequence>
 </xs:complexType>
 
       <xs:element name="Customer" type="cust:CustomerType" /> 
 
        <xs:complexType name="CustomerType" > 
  <xs:sequence>
    <xs:element ref="cust:FirstName" />
    <xs:element ref="cust:LastName" /> 
    <xs:element ref="cust:PhoneNumber" />   
    <!-- more stuff goes here like address, etc --> 
  </xs:sequence>         
  <xs:attribute name="customerID" type="xs:integer" />
 </xs:complexType>
 
       <xs:element name="FirstName" type="xs:string" />
       <xs:element name="LastName" type="xs:string"  />  
       <xs:element name="PhoneNumber" type="xs:string" />
       <!-- more stuff goes here --> 
      </xs:schema> 
 
The CustomerActionBase is an abstract type which means that the various departments can make specific elements referring to what actions to perform on a customer such as loans:collect-loan, loans:send-refund, loans:foreclose, etc and can all share the same definition of customer data. 
 
 
d.) I got your point, I just didn't agree with it. Let's roll this a notch back and look at relational databases since this is where most likely the customer information being stored will come from in the first place. Now it is quite possible that many thousands of departments in hundreds  of businesses have a database with the following schema 
 
create table foo{
 id integer, 
 fname varchar(50) not null, 
 lname varchar(50) not null,
 -- various fields including address, phone number, etc 
 primary key(id)}; 
 
 
Your protestations about XML Schema being relevant to providing semantics is like saying that sending the results of select queries prepended with the table name is enough to provide all the information necessary to process the data at any endpoint. For instance, imagine the above table was named "students" and was sent via EDI, SOAP, whatever to the financial aid department of a college and was now sitting in a processing queue. Does the fact that the name, ID, etc came from a table containing student information tell the financial aid department whether this message is directing them to disburse the student's loan, cut a refund check, or defer the student's payment obligations? 
 
XML Schema are about syntax not about semantics. Thinking otherwise is folly and will lead to creating fundamentally flawed architecture. 
 
PS: XML-DEVers, Clemens has indicated to me offlist that he cannot send mail to the list directly since he isn't subscribed but would like me to provide the following link to give more context to the original weblog post that started this thread 
 
<http://radio.weblogs.com/0108971/stories/2002/07/23/stayingSaneInAnXmlWe> http://radio.weblogs.com/0108971/stories/2002/07/23/stayingSaneInAnXmlWe <http://radio.weblogs.com/0108971/stories/2002/07/23/stayingSaneInAnXmlWebServicesWorld.html> bServicesWorld.html
 
 
-----Original Message----- 
From: Clemens Vasters [mailto:clemensv@newtelligence.com] 
Sent: Sat 7/27/2002 11:16 PM 
To: Dare Obasanjo; xml-dev@lists.xml.org 
Cc: rubys@us.ibm.com 
Subject: RE: On Schemas, Namespaces and Syntax vs. Semantics (long but worth it) :)



	In fact, "describing an incompetent organization" is my whole point.
	
	What I am saying is that since the folks in that other department didn't
	think long enough and had no rule written up somewhere that forced them
	to make the schema their own (because they clearly used the schema for
	another purpose than designed), the whole situation did happen.
	
	I've worked quite a few years on projects that deal with this exact
	business environment and you wouldn't believe how many terms' meanings
	are entirely reversed from "giving credit" to "reclaiming bad credit".
	So, the customer is a bit of a broad example. And, quote me fully:
	"[Author's note: The "customer" is an illustrative example to carry my
	point, but there are other, typically much simpler schemas, where such
	problems are even more likely to occur in the wild]"
	
	As to your proposals:
	
	(a) Processing instructions are, in my view, things that only a
	low-level technical infrastructure should ever worry about. If you want
	processing hints, create an additional schema/namespace and use
	attributes from that schema
	(b) xsd:any, xsi:type are things I like there.
	(c) How do you express that in schema properly? When you have expressed
	it in schema, how does it make sense?
	
	(d) You likely didn't get my point. Both organizations MUST HAVE their
	own schema, because for both organisations, the "customer" is a wholly
	different thing. A customer for /corporate credit/ is called a /debtor/
	at financial collections and submitted by their type of /customer/. The
	solution with two different schemas tell you exactly what to do with
	them , because you need to treat them differently from the start;
	otherwise your system will not understand....
	
	
	Same Ruby's blog can be found here: http://radio.weblogs.com/0101679/
	Mine can be found here: http://radio.weblogs.com/0108971/
	
	
	Best Regards,
	Clemens
	
	---------------------
	Clemens F. Vasters
	CTO, newtelligence AG
	Gilleshütte 99
	D-41352 Korschenbroich
	Germany
	
	MSDN Regional Director
	clemensv@newtelligence.com
	v-clevas@microsoft.com
	
	-----Original Message-----
	From: Dare Obasanjo [mailto:dareo@microsoft.com]
	Sent: Sunday, July 28, 2002 04:21
	To: xml-dev@lists.xml.org
	Cc: clemensv@newtelligence.com; rubys@us.ibm.com
	Subject: On Schemas, Namespaces and Syntax vs. Semantics (long but worth
	it) :)
	
	
	A recent discussion on XML-DEV[0] highlighted the fact that there is
	some disagreement amongst practitioners of XML as to whether XML schemas
	and XML namespaces are meant as a means of expressing syntax or both
	syntax and semantics which is excarberated by the fact that the W3C
	recommendations describing both of the aforementioned technologies do
	not offer any guidance.
	
	My personal and professional opinion is that neither namespaces nor XML
	schema offer enough capabilities to specify or even imply semantic
	differences to any degree beyond the trivial. I recently came across a
	post by Clemens Vasters[1] which helped condense for me why exactly I am
	wary of using either of these mechanisms for specifying semantic
	differences. Below is a condensation excerpted from his post
	
	"Assume you do work for a bank. The bank has, of course, multiple
	departments. The first department is corporate loans. They create an XML
	Schema to exchange customer information about between the main branch
	and their satellite branches. The schema only covers the base customer
	information (name, address, primary contacts, etc.).
	
	'Fine! This Schema fits our need just well to exchange all base
	information about our customers with our branches, as well' says the
	financial collections division,
	
	Note that the customer term means two different things here. A customer
	of corporate loans doesn't meet two consecutive payment deadlines. So,
	the corporate loans department hands over their customer data as a SOAP
	wrapped document to the "EDI mailbox" of the financial collections
	business where it is queued for processing. At the same time, the usual
	swapping of customer data happens between the branches of the financial
	collections business and get queued for processing in that inbound
	queue. Now, the customer in the sense of corporate loans is a debtor for
	financial collections and corporate finance itself is a customer in the
	sense of financial collections.
	
	Now we have two documents with the same namespace but entirely different
	business semantics stuck in the same queue. What to do?"
	
	Sam Ruby offered the following
	"As to your example, there is no question that two 'customer' entites
	that are semantically different should be modelled separately. "
	
	The funny thing is that I completely disagree with both authors. I
	disagree with Clemens Vaster for actually claiming that he has posed a
	problem since what he actually described is an incompetent organization
	and not a business case that highlights any failings of XML
	technologies. I disagree with Sam Ruby for a.) implying that using
	namespaces and/or schemas is data modelling and b.) that this is a data
	modelling problem.
	
	I thought of three possible solutions to this "problem" while reading
	Vaster's weblog and I'm sure XML-DEVers could think of more. The purpose
	of posting them to such a wide audience is to dispel the misconception
	amongst users of XML (especially the web service folks) that XML
	technologies are a magic pixie dust that can transform poor business
	processes and bad design decisions into a smooth oiled machine.
	
	Sending an XML document containg raw customer data without any extra
	semantic information is as useless as sending a fax without a cover
	sheet. Sam Ruby's suggestion [which implies using namespaces to
	dissambiguate] is akin to suggesting that instead of using coversheets
	all faxes should have be identified by appending the receiver's email
	address/office number/name to the end of each document. In most cases
	this will be sufficient but in any that require additional semantic
	information there will be no way to convey this. However with a
	coversheet one can scribble any extra instructions and explanation in
	the section provided. With my analogy done here are some [of many]
	potential solutions to this "problem"
	
	a.) PI solution: If some executive fiat makes it mandatory that only raw
	customer data must sent which conforms to the shared schema then
	processing instructions can be embedded in the SOAP message which then
	indicate to the final receiver of the message what to do with each
	customer.
	
	b.) Extensible schema solution: Again, if the same executive fiat
	applies then the original customer data schema is written in such a way
	as to allow for W3C XML schema extensibility (wildcards,  xsi:type,
	substitution groups, abstract elements and types, redefinition etc) and
	each customer although conforming to the schema has enough identifying
	information that it is clear how the data should be processed.
	
	c.) No brainer solution: Place the <customer> element information item
	within other XMl elements which indicate what semantics to use. E.g.
	loan defaulters are sent as <loan-defaulter> element information item
	with a <customer> element information item. 
	
	For completeness I should add the
	
	d.) Multiple schema solution: This is Sam Ruby's solution and it
	involves each division creating a schema for their customer data
	[although some repetition can be avoided by using a chamaleon schema]
	then each customer element information item is processed based on its
	namespace name. This solution however doesn't tell us what to do if one
	division may send customers to the collections department for different
	reasons which impact how they are to be treated. 
	
	I prefer my solutions to Sam Ruby's because they clearly emphasize the
	"it's just data" aspect of XML instead of embedding accidental semantics
	where one wants only syntax and data.
	
	[0] The thread entitled "Schema Namespace name, schemaLocation, and
	Schema Versioning" started by Mark Feblowitz earlier this month
	
	





 

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

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