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] Fallacies of Validation ... RE: [xml-dev] Are peoplereally

[ Lists Home | Date Index | Thread Index ]
  • To: Christian Nentwich <christian@systemwire.com>
  • Subject: Re: [xml-dev] Fallacies of Validation ... RE: [xml-dev] Are peoplereally using Identity constraints specified in XML schema?
  • From: "David RR Webber (XML eBusiness)" <w3c@drrw.info>
  • Date: Tue, 07 Sep 2004 11:43:00 -0400
  • Cc: xml-dev@lists.xml.org
  • In-reply-to: <91696150821.20040825151949@systemwire.com>
  • References: <15725CF6AFE2F34DB8A5B4770B7334EE03F9FBB1@hq1.pcmail.ingr.com> <200408251305.i7PD56M24854@smtp-bedford.mitre.org> <91696150821.20040825151949@systemwire.com>
  • User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803

Christian,

The 'single schema' approach only works in the limited case where the 
information is a small set, usually in a highly regulated and 
constrained domain.

Also - it also often works when people just do a 'one-off' interchange 
with limited participants.
So - they have some initial success - then try and scale across a whole 
community - and then
discover it is not going to be a simple linear growth path.  Not to 
mention the need to express
more than just the simple constriant rules and share those across the 
community.

EDI learned - and struggled to reel this in.  XML was supposed to solve 
this - but unfortunately
the implementers did *not* listen to what the real needs are - and the 
'Fusion of Five' needed to fully realize this.  The ebXML is finally 
getting there with the availability of mature Registries with 
vocabularies and nouns, CAM templates, BPSS, OWL and RDF.

Sure you can build quick schemas that work - but beyond that - you need 
to plan to augment your toolset to match the challenges of scaling up, 
versioning, business rule sharing, dynamic context handling, and 
business process definitions.

Cheers, DW

Christian Nentwich wrote:

>There is a lack of dissent here :)
>
>I'm not sure I buy the "there is no single schema" argument. There
>are reasons not considered here that you may want a single schema for:
>
>  - As a system contract. Swallow the pain, at least the schema is
>  a stable definition.
>
>  - As a surrogate for a legal contract (I'm involved with the FpML
>  standard for financial derivatives. Their schema is partly derived
>  from legal contract templates and having multiple versions around,
>  or letting counterparties mess with it is not something that would
>  fly).
>
>While we're on FpML, it's one of the few XML standards that publishes
>validation business rules. The rules are published in English and
>implementors are expected to stick to them. See
>
>http://www.idealliance.org/papers/dx_xml03/html/abstract/06-02-05.html
>
>for my XML 2003 paper/talk on the subject and http://www.fpml.org for
>the rules, published with every release.
>
>regards,
>
>Christian Nentwich
>
>-------------------------------------
>Christian Nentwich
>Technical Director, Syste/\/\/ire
>
>Semantic validation? Let's go...
>http://www.systemwire.com
>-------------------------------------
>
>  
>
>>Hi Folks,
>>    
>>
>
>  
>
>>>From reading yesterday's messages, I feel like the real issues are coming
>>out.  And the real issues, I perceive, are in the various fallacies with
>>validation.  Below I provide a start at listing the fallacies.  Your help in
>>elaborating these is needed.
>>    
>>
>
>  
>
>>Fallacies of Validation
>>    
>>
>
>  
>
>>1. Fallacy of "THE Schema"
>>    
>>
>
>  
>
>>2. Fallacy of Schema Locality
>>    
>>
>
>  
>
>>3. Fallacy of Requisite Validation
>>    
>>
>
>  
>
>>Let's examine each of these fallacies.
>>    
>>
>
>  
>
>>1. Fallacy of "THE Schema"
>>    
>>
>
>  
>
>>This fallacy was identified by Michael Kay last week:
>>    
>>
>
>  
>
>>>... there's no harm in using XML Schema to check data 
>>>against the business rules, so long as you realize this 
>>>is *an* XML Schema, not *the* XML Schema. We need to stop 
>>>thinking that there can only be one schema.
>>>      
>>>
>
>  
>
>>Yesterday Len Bullard made a similar statement:
>>    
>>
>
>  
>
>>>... most fundamental errors are ... to consider only a single schema.
>>>      
>>>
>
>  
>
>>and at another point Len states:
>>    
>>
>
>  
>
>>>... fall into the trap of thinking of THE schema and not 
>>>recognizing the system as a declarative ecosystem of schemas 
>>>and schema components.
>>>      
>>>
>
>  
>
>>Both Michael and Len are stating that in a system there should be numerous
>>schemas.  This is a big mindshift for me.  I admit being trapped into
>>thinking that there should be a single schema.
>>    
>>
>
>  
>
>>It would be very useful if we could have a simple example that shows how
>>several schemas might be employed, rather than a single schema.  Could
>>someone provide an example?  
>>    
>>
>
>  
>
>>Len, I like the term you used, "declarative ecosystem".  Could you elaborate
>>upon what this means?
>>    
>>
>
>  
>
>>2. Fallacy of Schema Locality
>>    
>>
>
>  
>
>>Yesterday Len also identified this fallacy:
>>    
>>
>
>  
>
>>>... most fundamental errors are to consider schemas only at the external
>>>      
>>>
>>system junctions ...
>>    
>>
>
>  
>
>>Len notes that many people think that validation should occur at a certain
>>place in the system, namely, at the outermost edges of the system.  (Len, I
>>assume this to mean the user-interface?)  Len argues that validation can
>>rightfully be done at many locations in a system.  Len, perhaps some more
>>words on this fallacy would be in order?
>>    
>>
>
>  
>
>>3. Fallacy of Requisite Validation
>>    
>>
>
>  
>
>>Yesterday Michael Kay made a very compelling statement with regards to
>>whether validation should be done at all in certain situations.  Michael was
>>responding to the example of an online service validating a user's address.
>>Here's what Michael said about the online service's insistence on validating
>>the user's address:
>>    
>>
>
>  
>
>>>The strategy (validating the user's address) assumes that  
>>>you know better than your customers what constitutes a  
>>>valid address. Let's face it, you don't, and you never  
>>>will. A much better strategy is to let them (the user) express   
>>>their address in their own terms. After all, that's what they  
>>>do in old-fashioned paper correspondence, and it seems 
>>>to work quite well.
>>>      
>>>
>
>  
>
>>Michael argues very effectively that in this situation it makes no sense to
>>do any validation at all!
>>    
>>
>
>  
>
>>I have not yet read all of yesterday's postings, so I may have missed some
>>other fallacies.  If you know of any fallacies that I missed, would you
>>please send them along?  
>>    
>>
>
>  
>
>>Also, if you have comments on the fallacies identified above, please send
>>them along.  Note: examples are much needed!
>>    
>>
>
>  
>
>>/Roger
>>    
>>
>
>
>
>
>  
>
>>-----------------------------------------------------------------
>>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>>initiative of OASIS <http://www.oasis-open.org>
>>    
>>
>
>  
>
>>The list archives are at http://lists.xml.org/archives/xml-dev/
>>    
>>
>
>  
>
>>To subscribe or unsubscribe from this list use the subscription
>>manager: <http://www.oasis-open.org/mlmanage/index.php>
>>    
>>
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
>
>  
>






 

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

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