Hi Pete:
Very informative.
As much as I like and will support the concept, I couldn't help but cringe that someone comes up with a new "web-based" system - and then defines their proprietary formatting for their config file instead of trying to reuse existing standards, e.g., adopting XML as a format.
I appreciate your thoughts. I've spent some time on this with ASRG,... see:
http://www.sortmonster.com/ASRG/index.html
What this effort and some practical experience has taught me is that XML tends to have a bit more overhead than is truly needed for some problems. It's an odd reality, but it turns out that XML may be "too good" to enable the first implementation of something like WOT, or even CPDL.
Implementing WOT as written is blindingly simple... and this is precisely because it leaves a lot of obvious problems unsolved... XML would solve many of those problems, but it would carry with it an implied requirement for lots of complexity and overhead. I discovered precisely the same conflict when working on CPDL at the point where I began to define import and export rules.
It turns out that in practice the characteristics of the required import/export model don't fit the inherent XML tools efficiently - in particular where in CPDL one defines the occasionally complex relationships required to define those transactions... In truth, it could certainly be done, but the solution would be far more complex than if the model for import/export were defined as a simple XML object that stays within the paradigm of the task.
So, I started down that road - and I was quickly faced with the inherent conflict.
If the import/export functions are handled in the "application space" by defining models in XML, then that import/export mechanism is redundant in some ways. The XML purists then insist that the correct way to handle the import/export mechanisms is by leveraging XML standards... There are good reasons for this, and having two ways to essentially include another file is not only redundant but also leads to ambiguity and complexity... So, having lost the debate we decide to stay with pure XML... but... If we head down that road we end up with a solution that is correct for XML, but wrong for the application... Further, the engine implementing the application must now faithfully implement all of the XML standard(s) in order not to cause problems down the road when some enterprising XML specialist attempts to take advantage of capabilities that are implied to be present.
End result: Do it with XML and the cost of the project far exceeds it's immediate viability. Do it with some simple alternate standard and the cost/benefit ratio of the project becomes vanishingly small - at least up front.
I've run into a similar paradox recently with new Message Sniffer features. Clearly it is time to implement a configuration file since current and future upgrades will require some complex parameter sets. Clearly the best solution to coding that configuration file is via XML (for many reasons). However, in attempting to code such a thing I quickly discover that the cost of the XML solution far outstrips the available budget(s) and would delay deployment unreasonably... Oh I hate it, but the only practical solution for the immediate term is to create a simple, straight forward configuration file and then suffer the support issues involved in converting to a more comprehensive XML based solution later when budgets permit.
Having faced so many of these cases in recent days I find I cringe less often when I see things like WOT show up. In practice, something like WOT that is so simple is far more likely to succeed in these early times. Packaged as it is, WOT is a virtually no-cost potentially high-benefit solution... You and I know that as it grows it will run into real problems and limitations that would never arise if only it were done with XML at the start... and perhaps when these limitations become important (or even before) someone will convert the project or present a working alternative. Perhaps, like a Windows desktop that must be rebooted 3 times a day as a matter of course, it will always be good enough just like it is. (Sorry M$ fans, I just had to take the shot - it was too obvious ;-)
None the less, if we saddle WOT with the burden of XML compliance right now, then we can virtually certify it's death on the vine...
I forget where (maybe MIT or CMU), but I recently read a research paper that describes precisely this dynamic at work. It was titled something like: The wrong solution always wins. I'm not sure of the title - I'm paraphrasing... but I remember that coming across the thing really made my blood curdle. Then as I read it and did the math my life flashed before me - every battle I'd ever fought to build the perfect product only to have it shelved before deployment, any project I ever worked on that was canceled before it got started, all of those war stories and nightmares where top notch engineers and designers shake their heads at the insanely bad choices made by their clueless managers or even less enlightened end users... all of those scenarios boiled down to the same economic realities.
So, anyway,... Ultimately I agree with you that XML is probably the best way to go about the whole WOT thing, and in fact CPDL could include WOT (or even Declude configs) if defined in XML with numerous benefits... eventually we may even do just that. (or not)
But in the mean time, if we want to see WOT done at all, let it rip as is - head on toward the wall with the afterburners lit... just be prepared to install a steering wheel at the last minute -when the budget arises ;-)
"Kick the tires and light the fires!"
_M
--- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
