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

[Henrik Martensson <henrik.martensson@bostream.nu>]

On Tue, 2004-06-08 at 05:06, 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.

Agreed. Still, _if_ there is a way to make them conform to the same
format, that is preferable.

I am lucky in a way, because in most of the projects I work in, it is
possible to do that, and I usually work with the team that does it.

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

I agree again. :-)

And once again, I'm lucky, because creating such quality control
processes is often part of my job. (The not so lucky bit is that some
customers hate the very notion of quality control, so it is not always
possible to implement a good system, but that is another matter.)

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

And once more, we agree.

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

Some of the projects I work in do have small teams, working in close
physical proximity. Others are more sprawling affairs, with several
teams, located on different continents.

Common goals, a willingness to give and take, and a high degree of
technical competence all around are key ingredients in a successful
project. Then again, developing XML systems isn't different from
developing other things in that respect.

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

I agree again. There are other factors though. For example, it is
necessary to factor in the consequences of not achieving conformance in
terms of monetary loss, personal injury and death. When dealing with the
automotive industry, military systems, or telecommunications, as I often
do, misused tags are costly at best, at worst they kill people.
Therefore, conformance has a very high priority.

/Henrik