[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] The waterfall model lives? (was Re: The subsetting has begun)
On Sat, 22 Feb 2003 05:21:15 -0500, Daniel Veillard <veillard@r...> wrote: > My guts feeling is that your problem is a framework one not a > problem with the XML spec purely and to be perfectly frank the > reliance on Java just makes the 2 of the 4 points I just pointed out > insanely large. Still it's not a valid justification to blatantly break a > well established specification. > Fix your parsers/framework instead of tweaking the spec to get the > overall solution to fit your constraints :-( I find this whole discussion a bit disorienting. I sortof hate it when I disagree with so many people who I respect and generally agree with, and have rethought my position many times over the last few years. Still, I don't agree with the argument that the XML 1.x specification is the fixed point around which the "XML world" (broadly defined) should revolve. It reminds me of the "waterfall model" of software design/development: requirements are gathered, written down, reviewed, and cast in stone; designs are devised, written down, and cast in stone; then the design is implemented in code, the code evaluated against the requirements, and tweaked until the requirements are met. This is more or less a strawman in most software engineering texts that I've seen in the last 20 years or so, but it seems to be treated as incontrovertible truth when we're talking about the XML spec. The larger world of software engineering has come to terms with the fact that the world changes faster than we can write specs (which is after all more of a political process than a technical one), that technology changes can make engineering tradeoffs in designs (and assumed in requirements) obsolete very quickly, and that the only way to keep projects from degenerating into chaos is to have some sort of tight feedback "spiral" among requirements, designs, and implementation. In this case, "XML" (I agree with the critique that whatever this J2ME subset thingie is, it's not XML 1.x and Sun should make that crystal clear) is being put to uses and in environments that were AFAIK outside the expertise of the original XML WG. They made plenty of requirements/design tradeoffs in subsetting XML to meet the needs of the Web of backoffice servers and desktop browsers.The last 5 years has shown that to a VERY great extent, they made good tradeoffs, and XML has been far more successful than anyone (at least that I knew of back then) predicted. But AFAIK they weren't thinking about Java VMs running on cellphones, or enterprise-class transaction processing engines handling thousands of messages per minute. It's not surprising that XML 1.0 is turns out to not be exactly optimal for these environments. What does surprise me is how reluctant the XML community is to apply the techniques we've learned for building robust software to building robust specifications. Monoliths are fragile, but layered, modular architectures are adaptable. External realities change, and requirements have to be able to change or they will be bypassed. It looks to me (from a distance) as though the J2ME people are doing the Right Thing -- setting up tight feedback loops among requirements, designs, and implementations and weighing the business value of each. Sure they've tweaked the spec to fit their constraints, but to do otherwise would be to set themselves up for failure, as so many software projects following the "waterfall" approach have over the last few decades. I'm afraid that I think that it's XML that needs to accomodate the requirements of its "customers" by becoming more modular so that people in Sun's situation here aren't faced with a stark choice between being non- compliant with any spec, and bloating their code / making products more expensive in order to comply with parts of a monolithic spec that (apparently) add little business value. So what if XML were "refactored" so that the bare-bones well-formed syntax (and/or data model, that's another issue!) were the common core, and DTD processing were at the next layer up? That would solve the J2ME issue, address the high-speed SOAP processing issue, standardize the "Common XML Core" that is the rock-solid basis of de facto interoperability, and so on. DTD users won't suffer by avoiding implementations that clearly don't meet their needs. Other users gain, since as a practical matter raw XML with entity references isn't going to go out to a cellphone anyway, and not too many Docbook documents are likely to be seen in thousands-of-transactions- per-minute environments. And having an identifiable conformance level to explictly check against (J2ME would be clearly labelled as conforming only to "XML Basic" or whatever) would tend to prevent nasty surprises. And if Moore's Law or the growth of XML Everywhere leads to a demand for Docbook on cellphones, well then J2ME can just evolve to meet changing realities like everyone else has to. (Or more likely the use case for J2ME itself will disappear, but such is life). Sigh, another half hour lost to this permathread ... oh well.
|
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
|