Re: [xml-dev] The triples datamodel -- was Re: [xml-dev] SemanticWeb permathread, iteration n+1

[Rick Marshall <rjm@zenucom.com>]

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 ;)

rick

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

begin:vcard
fn:Rick  Marshall
n:Marshall;Rick 
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard