|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: What is the advantage of RELAX in comparison to Schemas?
Agreeing that both cases have valid uses, I would argue that the legacy rules are still the rules of consensus and that the requirement to "drag in a programmer" is an unfortunate side effect of the original implementation (eg, WYSIWYG botched document production by hiding an unmodifiable schema). Keeping up multiple documents to control a single instance is a cost, no doubt, but spreading a single ineffective control across multiple processes with different objectives is also costly. Again, the case must be made for consensus and that is harder than to rule by fiat. The problem is that when one attempts the monolith it is likely that acceptance and implementation may be sparser than if only the simplest and easily recognized agreements are made (this is Berners-Lee minimal victory approach). Sometimes minimalism is better; sometimes it only delays the implementation. Requirements analysis first, of course. I agree that having only one definition from an agency that by the illusion of authority is promoted is bad. Multiple definitions which do not enable a process to remain coherent is also bad. Therefore, the engineers have to actually ask the users which they prefer. (Note, I didn't say, ask the managers.) My position is that these multiple means do not compete but could be construed as such depending on the means used to choose the means. Semantics is a means to choose among means. I think that is why some are starting to look very seriously at concept modeling as a layer over XML modeling for large systems where by large systems, I mean, multiple authoritative scopes of control. Len http://www.mp3.com/LenBullard Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h -----Original Message----- From: Bob Kline [mailto:bkline@r...] The problem with separating out context rules into the application is that we would undermine one of the primary benefits of the current project to replace the customer's legacy document creation/maintenance system, in which it is impossible to modify document structures or business rules without dragging in a programmer. The problem with separating out context rules into a separate document (such as Schematron) is the standard one of keeping modifications to separate specifications of the document structures in sync. We could ignore W3C's schema syntax altogether and simply adopt one of the competing models (e.g., Schematron or RELAX) but this path incurs the risk of much lower levels of support from third-party toolsets. It may well be true that for some projects separating out different components of document constraints will be the most appropriate approach. It is unfortunate, however, that the spec most likely to attract third-party support (by virtue of its sponsorship by W3C) assumes that this is the *only* valid approach.
|
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
|
|||||||||

Cart








