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 13:05, John Cowan wrote:
> Henrik Martensson scripsit:
> 
> > You will also have to work on maintaining these 50 stylesheets
> > continuously, because things will keep changing. And you will have to
> > make sure that these 50 stylesheets are also used at the other 49 sites,
> > and that the continuosly update with new versions of your stylesheets.
> 
> The first point is sound, but the second one isn't.  In a publish/subscribe
> world, each of the 50 companies is responsible for getting inputs into a
> form they themselves understand.  A good analogy is that of learning

I meant one company, 50 sites. For a single company to spend that much
effort updating DTDs for internal communications is not efficient.

Also, there are more efficient ways to handle communications between
companies. Exchange DTDs do have their own set of problems, but using
them is much more efficient than trying to keep up with one format for
everyone in the same market segment. There are industry standard schemas
for the automotive, electronics, telecommunications, military, and other
industries. Using them is much cheaper than building filters for every
format that exists in a particular industry.

> languages: if we have enough clout, we can insist that other people learn
> our language so we can talk to them, but in the end it's they who must
> learn (or not) to convert our input into what they understand.  That
> knowledge is not (directly) exportable.
> 
> > Funny you should bring XP up, because XP takes a very rigid approach to
> > testing, or validation. Automated tests are written first. Software must
> > pass the tests, or the entire development process is stopped until the
> > problems have been fixed. Duplicated information (duplicated code, or
> > for that matter, different tags that do the same thing) is simply not
> > tolerated.
> 
> That directly applies only to one's own code and data: it can't possibly
> apply to other people's with whom one has no contract.  Imagine how much

XP concerns itself with small teams, about two to twelve people. Within
that group, it is as I described it.

For larger projects, involving more than one team, Scrum and DSDM, among
others, offer techniques for scalability.

There is always a contract of some sort. Without it, communication is
not possible.

> money would be lost if Walter's systems shut down every time a malformed
> document was fetched!  (In practice, few documents are too malformed to

Why would Walter's system shut down? Validation just tells you that
something is wrong, it does not shut a system down, nor does it preclude
you from fixing the problem, manually or automatically.

> understand, or he wouldn't make money at all.)  In a world of financial
> instruments, the rule is "execute when you get it, back out later if
> necessary, make everyone whole".  This won't work if the domain is
> surgery, but there's no reason to expect every domain to be the same.

Exactly the point I have been trying to make. Different domains are,
well, they are different. That is why it is wrong to claim that
validation is the wrong thing to do. Sometimes it is appropriate,
sometimes it is not. When dealing with human authored documents, it is
usually very appropriate.

/Henrik