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 ]

all is well so long as the XML communicates any break in 
backwards compatibility, either by changing a namespace
or adding a 'mustUnderstand' flag to the new extension. 

A change in the semantics which breaks processing an earlier
version of a document without such signals, e.g. changing 
price from Pounds to Euros or adding a country to an address
without a sensible default is a break in compatibility and 
would certainly be valid concern to a lawyer!


-----Original Message-----
From: Rick Marshall [mailto:rjm@zenucom.com]
Sent: 08 June 2004 05:31
To: Thomas B. Passin
Cc: XML Developer List
Subject: Re: [xml-dev] The triples datamodel -- was Re: [xml-dev]
Semantic Web permathread, iteration n+1

and if the schema changes, but not the xslt, and someone suffers 
financial loss - tax returns fail, orders lost, etc - who pays?

or will this be a whole new endeavour for lawyers? do i need extra 
profesional indemnity to cover what happens when you change something 
without telling me?

this thread is starting to worry me....


Thomas B. Passin wrote:

> Henrik Martensson wrote:
>> On Sun, 2004-06-06 at 20:19, Thomas B. Passin wrote:
>>> Better to be good at xslt!
>> What would you have done if you had to deal with information from fifty
>> different sites, and all fifty made their own, frequently incompatible,
>> changes? (This is a far more common situation in my line of work than
>> having to deal with only one data provider.)
>> Writing fifty different XSLT stylesheets does not sound like a good
>> solution.
> It sounds pretty good to me, if I don't have a way to arrange for all 
> of them to supply the same format.
>> I can understand your reluctance to require that the data provider
>> conforms to a particular schema when you are dependent on them, instead
>> of the other way around.
> It wasn't our reluctance, but the near (or total) impossibility.  But 
> note that in this case, unlike the second vignette I posted, we were 
> working to a schema, in fact, two of them - theirs and ours.  The fact 
> that their schema itself had some technical errors that I had to 
> correct (and informed them about), and that it was a little out of 
> sync with the actual delivered format, tells me that they did not have 
> a complete process in place for managing quality control.  And this is 
> not unusual.
> Here's the thing ... there is no one solution because all the cases 
> are different.  XML has a remarkable ability to cope with so many of 
> these environments, which is perhaps one reason it has insinuated 
> itself into so many places.  In a case where there is a closely 
> connected team, and all parties can be forced or pursuaded to use a 
> given schema, you may be able to achieve everybody's conformance.
> Other cases are more Walter Perry-ish, and that approach is not an 
> option no matter how desirable it would be.  And there are all degrees 
> in between.
> Cheers,
> Tom P


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

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