Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The Knights of Tag Soup (was Re: RE: evolvable f
 Mike Champion wrote: > Uche Ogbuji wrote: > >This sounds like the rallying cry of the Knights of Tag Soup. > > > >Validation is mostly an obstacle to evolution if designed using the wrong > >tools in careless hands. > > That's a great turn of phrase! Still, I guess I think of myself as at > least the jester in the Court of the Knights of Tag Soup, so maybe I > should ask Uche or someone else to educate me on the point. > > Uche's point was a response to a response to something I wrote: > > > 2 - Namespaces - work best for mixing instances of well-defined > > vocabularies/schemas together, they don't work so well to support > > evolution or un-typed XML. Schema evolution using namespaces is > > a Known to Be Hard, TAG-level problem. > > I'm under the impression that managing schema evolution > is a Hard Problem; As with the Halting Problem, managing schema evolution is only a Hard Problem in theory; in practice it's generally quite tractable. The hard problem is: "write a program that will compare two versions of a schema and determine if all documents valid under version 1 will remain valid under version 2." This isn't halting-problem hard, but it's not trivial either. In practice, the question "is version 2 of *this DTD* backwards compatible with version 1 (in the sense above)" is usually straightforward to answer, especially if both versions of the DTD are designed with that question in mind. Validation is far from being an obstacle to evolution; in fact, it's an essential ingredient. The "works in Netscape" test only tells you if your data will work with the current versions of the programs you happen to test it with. Validation against a schema tells you that your data will work with *any* program that can process documents conforming to that schema; and, if the schema is evolved correctly, with any *future* versions of those programs. (Alas, the "works in Netscape" test is still necessary for web pages; validation alone isn't sufficient in the face of browsers that don't implement the standards correctly themselves.) > lots of the complexity > of WXS is there to make the problem more manageable by employing > notions of partial re-use that come from the OO world, but it's > not clear to me that best practices have emerged for using it. I don't know about WXS, but plenty of best practices have been devised for DTDs, most of which are equally applicable to RELAX NG and other reasonable schema languages. [ ... ] > Finally, how DOES one make XML technology choices that are not fragile in the > face of human nature? So much of traditional SGML/XML technology seems > predicated on the assumptions underlying the "waterfall model" of software > development. Not really; the waterfall model doesn't work any better for SGML than it does with anything else. SGML is very well-suited to iterative application design, where the markup, DTD, and processes evolve in parallel. The DTD is the cornerstone of this approach: it specifies the contract between the data and the processes. Keep all three in sync and you can maintain a working system at each iteration during initial development. At upgrade time -- when deployed processes and existing data will be out of sync for a while -- the DTD is an important tool in assessing the impact of the change. --Joe English jenglish@f... 
|
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
|
|||||||||
