[
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!
Paul
-----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....
rick
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
>
|
