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 00:57, Elliotte Rusty Harold wrote:
> At 11:00 PM +0200 6/7/04, Henrik Martensson wrote:
> 
> >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's easier than getting 50 different organizations to agree, and 
> then to conform to that agreement. 50 different stylesheets is not 
> that hard, especially when most of them are likely to be simple 
> variations of each other. I can easily write 50 stylesheets in 50 
> days, probably less. I'd be very surprised if 50 companies could 
> agree to anything in 50 days.

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.

> 
> >For me it is different. I work with fairly large companies. The data
> >providers are either departments or subcontractor. In such situations,
> >trying to adapt to everyone else simply does not work.
> 
> Why not? Have you tried it and watched it fail? If so, please do 
> elaborate on your experience. If you'd like I can probably get you a

Yes, I have. I did mention a company with 170+ different formats, that
allowed authors to make up their own markup. They nearly went bankrupt a
couple of years ago.

I'll give you one small example of what caused the chaos :

At one site, the management decided to update the documents. They did
the following:

* Removed all document numbers from reference lists in documents,
  so that they depended entirely on document titles to identify
  related publications
* Changed the tagging so that what had once been a document type
  "User Guide", "Reference Manual", etc., became the document title

As a result, all documents of a particular type ended up with the same
name, and names where all customers had to go on when ordering new
documentation, or trying to locate information in the documents they
had. It wasn't pretty.

Actually the documents weren't XML documents at the time, but the same
principles of the effects of arbitrary markup changes apply. There was
of course a substantial impact on existing plans to convert the
documents to XML.

>  
> slot at SD 2005 West to talk about it. (They love case studies.) But 
> like extreme programming, nobody believes this approach can possibly 
> work, until they try it and see that it does. And then they can 
> hardly believe they ever did it any other way.

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.

Systems developed using XP tend to be flexible and robust, have very
good error handling, and can recover from many faults on their own. They
do not ignore potentially unsafe situations in the manner you advocate.

I have been using XP for a couple of years now, and I like it very much.
(I recently switched jobs, partially to be able to work with other XP
developers.) I can imagine other ways to do things though, and I use
them when circumstances warrant it. (For example Scrum, RUP, LSD - not
the drug, Pragmatic Programming, and when nothing else works, fits of
screaming, depression, or laughter.)

BTW, I do apply test driven development, and refactoring, as well as the
other XP practises, including pairing when I can, when I write DTDs. I
have found it very useful. Tests that validate documents against the
DTDs are important parts of the automated test suites.

If you like XP, you have probably read as many XP books as I have, and I
suppose books about XP practises like TDD and refactoring too. However,
I would like to recommend a couple of interesting books. They won't make
us agree, we will probably end up disagreeing even more, but they are
good books, well worth reading for their own sake:

* Lean software Development, by Mary and Tom Poppendieck. This book is
  about the principles behind XP and other Agile methodologies. There is
  a lot of material here that is pertinent to our discussion.
* Lean Thinking, by James P. Womack and Daniel T. Jones. This is a book
  that agilists keep referring to, so it is worth reading for that
  reason alone. There are plenty of examples of value stream
  mapping, and of the importance of fixing problems at the source.

/Henrik