- From: Michael Kay <mike@saxonica.com>
- Date: Mon, 12 Sep 2022 12:16:16 +0100
- To: Norm Tovey-Walsh <norm@saxonica.com>
- Cc: public-xslt-40@w3.org
> >> - "if implementors raise strong objections" >> -- All implementors? Some implementors? Would a strong objection from >> a single implementor be sufficient to reject a proposal? > > I’m not sure how to gloss this one. If we want to finish this effort in > a small, bounded amount of time, we need some sort of escape valve for > folks who are actually going to be writing code that implements the > specification to say “look, it’s a cool idea, but it’ll take a decade to > get right, let’s not put it on the critical path for v.next”. > There are two relevant scenarios here. The first is where specification is difficult or complex. Examples of such features from the past in XSLT have been schema-awareness, streaming, and packaging. These have been strategic enhancements, which took years to specify, and which have turned out to be of interest to only a minority of users, though the value those users get from the feature is high. In the first two cases the feature has been made optional, because putting together a business case for doing an implementation is not easy. But even if the feature is optional, the amount of time devoted in the working group to thrashing out the specification was immense, and I want to avoid taking on any such projects. The second is where specification might be fairly straightforward, but implementation can be challenging, often because suitable libraries are not readily available. An example might be a decision to require xs:decimal arithmetic to be supported with a minimum precision of 100 digits. That's easy to specify, but it's challenging to implement if you happen to be in an environment where no suitable library is available. The key thing in both cases is to be realistic about costs and benefits. Standards activities that lose sight of how to balance the benefit to the user community against the cost of implementation tend to fail. And we're definitely looking here (in my view) to get agreement on low-cost high-benefit features. We're also looking primarily to users for assessment of the benefit and to implementors for assessment of the cost. Michael Kay Saxonica
Received on Monday, 12 September 2022 11:16:33 UTC