Re: The triples datamodel -- was Re: SemanticWeb per
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format