[
Lists Home |
Date Index |
Thread Index
]
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
|
