[Home] [By Thread] [By Date] [Recent Entries]
Michael Champion wrote: > Rick Jelliffe wrote: >> Stan Kitsis wrote: >>> In my experience API-level support is an order (or two) of magnitude >>> more expensive than delivering UI apps. First of all, the testing >>> costs are much higher. Second (and way more significant), once we >>> realease an API, we will have to support it for 10 years or so - and >>> this is extremely expensive. >>> >> I hadn't heard that applications with User Interfaces were so cheap >> and easy to deliver. > Note that Stan stressed the second point, that Microsoft shipped APIs > have to be supported more or less forever, so the up front test costs > are enormous. If we're talking about RNG, I can very easily see the > costs in the multiple millions of dollars -- for test case writing, > implementation on .NET and native platforms,stress testing, > performance tuning, extensive security scrutiny, integration with the > rest of the stack, documentation for mainstream audiences, and so on. It sounds like the cost driver is labour; is the multiple millions of dollars estimate for programmers at US rates? I think one of my points was not clear, especially since I switched over to talking about Schematron, hijacking an already hijacked thread :-) A technology that cannot be evolved is dead. The way I was suggesting for RELAX NG support was incremental, not requiring *any* RELAX NG integration into the big picture stack; instead my suggestion is just to provide the most simple validation API and make it part of the .NET distribution. Make up some quality constraints and invite an open source implementation, and let your RELAX NG strategy be "We will distribute it as soon as a non-viral open source implementation comes along that meets our quality requirements for testing and documentation, and uses this API. People can use it if they need, but we provide first class support for XSD only." People can convert from RELAX NG to XSD if they need to, so you don't need to replace XSD at any other level or tools. My other point was for vendors to use their influence on W3C XML Schema WG so that XSD grammar evolves, albeit slowly, in directions that are consonant with RELAX NG. In XSD terms, component compatability rather than syntactic compatability. To give a practical example, the XSD WG was looking at how to add some kind of co-ocurrence constraints. One way they could do it would be to add little guard statements, like embedded Schematron assertions. Another way would be to upgrade the key/uniqueness sublanguage. Another way would be to upgrade content models so that attributes are allowed as particles. Following this last approach has the benefit of aligning with RELAX NG more. You could say that same issue with an enhancing xsd:all towards RELAX NG's interleave. It would be great if MS were to use its influence to push the W3C XML Schema WG away from any NIH-ism and towards modularity and alignment with RELAX NG components; the issues of syntax and namespace should be matters of branding and user-friendliness rather than signifying component-level non-interoperability, IYSWIM. Of course, I suspect MS and other large vendors don't want any change in XSD at all, because of the ramifications, in the same way that MS is not supporting XML 1.1 or XSLT 2. I wonder if Michael has any comment on this? Does MS have any commitment to tracking standards, either for minor-version-number changes or major-version-number changes? B.t.w., the line that providing RELAX NG will confuse people badly doesn't sit well with me; people manage not be confused that MS provides C++ and Visual Basic and they both are programming languages. A decision point is not confusion. Anyway, if confusion is so bad, what on earth is MS doing with XLinq versus XSLT2 versus XQuery versus SQL? ;-) Now that *is* confusing! > ... I encourage people who hit the wall with XSD in the Microsoft > environment to try out Schematron constraints, use the reference XSLT > implementation, and see if that works for them. Thanks Michael! Cheers Rick Jelliffe
|

Cart



