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] SemanticWeb per

[ Lists Home | Date Index | Thread Index ]

unfortunately for me the multiple customers with different formats use 
excel files, csv files, pdf files, edi files, etc in fact none of them 
use xml yet so perhaps xml would be a small step forward. but then a 
dozen or so large and small software houses have to change their 
software too. it's a long and winding road ;)


Michael Champion wrote:

> 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.
> -----------------------------------------------------------------
> 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>

fn:Rick  Marshall
tel;cell:+61 411 287 530


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

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