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 07:20, 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?

"Validating" does not mean "breaking". It is the other way around.
Validation is one form of error checking. It is when you don't check for
errors that you end up with brittle software. Worse, you can end up with
software that produces insane results without notifying anyone. This can
be a killer, literally.

Imagine a document formatting system that just ignores unknown tagging,
the way Elliott proposes. Now imagine that an author invents a new
admonition tag for a particular market. (The U.S. and Japan have special
requirements, so European manuals published in those countries would
need some way to distinguish admonitions that must be processed
differently than in other countries.) As a result, the market specific
part of the document will either be omitted entirely (worst case) or
formatted the wrong way (best case), probably just like any other block
of text. Either way, if an accident happens, the company that publishes
the manual would be liable to pay damages.

The worst thing is, if the information had been included in the
document, in the proper manner, the accident might have been avoided
entirely.

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

With XML, all hell still breaks loose when the format is changed. XML is
no different from other formats in this respect.

The difference from procedural formats, is that with XML there is no
need to change the format to enable new features in processing software,
as long as those features do not require new information. In many cases,
new information isn't needed, provided that the original markup is
reasonably good. (At Ericsson, switching to SGML meant changing formats
about once a decade, as opposed to switching every year, as they did
before. This meant considerable savings, because they did not have to
update their software as often. In effect, their software was much more
robust.)

As a result, XML formats can be more stable than procedural formats, and
therein lies a major advantage of 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.

This is a misunderstanding. XML software can be flexible, adaptive, and
robust _because_ the format is well defined and stable, not in spite of
it.

You somehow equate flexibility with changing the markup anytime,
anywhere. This is very difficult for me to understand. A format that is
flexible does not have to be changed as often as a format that isn't.

When you start making frequent changes to XML formats it is no different
from when Microsoft makes changes in the MS Word format with every
release. (To their credit they have realized that this is bad, and are
much more careful about such changes now than they used to be.)

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

There is a difference between loosely coupled and arbitrarily changed.
No one is against loosely coupled systems. The "validators" want error
checking and error management, it is as simple as that. To what degree
this is needed, depends on the circumstances.

There is nothing wrong with well formed XML per sé, it is just that
there are situations where it should not be used. Information
interchange between decoupled systems is one of them.

For the record, if two systems exchange information, and changes in one
system mean that the exchange format has to change, the systems are
_not_ loosely coupled. There has been a tendency in this thread to
equate "loose coupling" with "ignoring changes in couplings", but this
is wrong. Loosely coupled systems must still play by the rules they have
agreed on.

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

This is still a very common use case.

> 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 

In which case one uses Thomas' approach, writes a lot of import filters,
to get all the data into a common format, then one processes that. (And
one might be cheerful about it like Thomas, or grumble like me, but in
the end, transforming to a process DTD/schema is the way to go in such
situations.)

Trying to implement every nutty idea from every user with '<' and '>'
keys on their keyboards is an extremely bad idea.

> 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  

As in having people die in munitions accidents, you mean, because that
is the kind of thing that happens when automated systems mess manuals
up.

> the customers to send orders in a rigidly defined format probably 
> doesn't need XML in the first place.

Actually one does. There are precious few alternatives.


/Henrik