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] The triples datamodel -- was Re: [xml-dev] Semantic Web pe

[ Lists Home | Date Index | Thread Index ]


On Jun 8, 2004, at 12:31 AM, Rick Marshall wrote:

> and if the schema changes, but not the xslt, and someone suffers 
> financial loss - tax returns fail, orders lost, etc - who pays?
>
And if nothing can change, because everything will break, and everyone 
suffers from missed opportunities, who pays?

This is sounding like "the worst feature of X is is the one that made 
it successful" subthread:  Before XML (and related technologies) people 
had little choice but to stick with rigid formats, because all hell 
would break loose when they were changed.  People are jumping on XML 
and the design philosophies it enables  because there has been a pent 
up demand for more flexibility.  Naturally that can be overdone and has 
downsides as well as upsides, just like most technologies.

I'm not sure why one would bother with XML at all in a situation where 
horrible things happen when uncontrolled evolution occurs -- XML can be 
made to work in tightly coupled systems, but I don't see what advantage 
it has over proprietary object or database interchange formats if you 
want things to die quickly and cleanly when closely shared assumptions 
are violated. I can think of some, such as the classic SGML use case of 
maintenance manuals that must work across a wide variety of systems but 
must also conform to precise structural specifications. Nevertheless, 
the "I've got 50 customers who want to send me orders in conceptually 
similar but syntactically diverse formats" use case is a lot more 
typical IMHO.  The typical options are between using a technology  that 
can gracefully accommodate diversity and change (and paying the price 
of occasional breakage), and having humans transcribe information from 
diverse input formats into an internal standard (and paying a much 
higher  price for every transaction ... and you still have to pay the 
price for human error!). Anyone who can avoid the dilemma by requiring  
the customers to send orders in a rigidly defined format probably 
doesn't need XML in the first place.





 

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

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