- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Mon, 10 Oct 2022 16:27:27 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m2tu4b4rs9.fsf@saxonica.com>
Hello, Persuant to my action, here is an attempt to incorporate the feedback that arose from our last discussion of the process document. Six meetings in, we seem to be functioning smoothly and making good (if, as always in standards groups, slow) progress. I hope that the initial drafts of this document were useful in setting us on a positive course. I don’t propose that we bring this back on the agenda for further discussion, unless there is demand for it. If no one objects, I’ll find a place to put it on the qt4cg.org page. === The community group (CG) aims to agree to extensions to the XSLT 3.0 Recommendation published on 8 June 2017 and the XQuery and XPath 3.1 Recommendations published on 21 March 2017, along with supporting changes to the other specifications (XPath, Functions and Operators, Serialization, etc.) on which these depend. A preliminary proposal describing requirements for such extensions can be found in Michael Kay's Proposal for XSLT 4.0 published in the Proceedings of XML Prague 2020, https://archive.xmlprague.cz/2020/files/xmlprague-2020-proceedings.pdf#page=121 This has been supplemented by a wide variety of proposed enhancements which are registered as issues against the GitHub repository, https://github.com/qt4cg/qtspecs/issues It is intended that the group will operate through the use of email and other online communication together with weekly conference calls. Formal progress will be made through minuted decisions made at the weekly conference calls. The scribe will publish the minutes as soon as practical after each meeting. Our common goal is to define additions and other changes to a family of specifications. To that end, as described below, we expect that well-defined proposals for changes will be made and those proposals will be accepted (or not) according to the consensus of the group. The terms “well-defined” and “consensus” are open to interpretation. No attempt is made here to define them precisely. A precise definition is only necessary if an issue has become acrimonious, at which point, precision isn’t going to contribute usefully to a mutally acceptable resolution anyway. Informally, we could say that a proposal is well-defined if it is clear and complete if it’s laid out in sufficient detail that an editor could apply the changes without having to make additional technical choices. If that’s not a useful metric for some proposals, one alternative formulation would be that it’s laid out in sufficient detail that someone could write a comprehensive set of test cases for the proposal. Merriam-Webster defines consensus as “general agreement.” We should strive for unanimity, and work cooperatively towards a mutually satisfactory solution where it doesn’t exist. It seems likely that if one or more members are strongly opposed to a change, then it hasn’t achieved consensus. Broadly speaking, we expect the group will proceed as follows: + Technical debates should be held primarily offline; issues will only be placed on the agenda for a group call if (a) there is consensus behind a concrete proposal for the group to ratify, or (b) there is a clear choice to be made between competing proposals, or between making a well defined change or leaving the specification unchanged. + The default decision is to preserve the status quo (the existing specifications) unless there is a consensus to do otherwise. + Specifications without implementations have no value. The group should strive to be realistic about costs and benefits. Our focus should be on delivering the highest benefit features that are of at most moderate cost to specify and implement. We anticipate that users will, generally, have a sense of the benefits of a feature and implementors will, generally, have a sense of its costs. + There is a strong presumption in favour of retaining backwards compatibility. Incompatible changes will only be made for "edge cases", and only if there is clear evidence that the existing specifications cause serious problems for users or implementors. + There is a strong presumption against changes to the data model, on the theory that changes to the data model tend to have many knock-on effects that can take years to work through. + Before accepting a proposal, there must be agreement that it is well-defined. It must not leave apparent technical questions unanswered. Applying a proposal to the specifications should be an editorial process that doesn’t require additional technical decisions to be made. + The editor will as soon as practicable after each meeting update the draft specifications on GitHub and republish them, with change markings. Members are expected to check that the specifications have been updated correctly and to report any errors found as GitHub issues. Be seeing you, norm -- Norm Tovey-Walsh Saxonica
Received on Monday, 10 October 2022 15:34:00 UTC