- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Fri, 05 Jul 2024 09:06:24 -0600
- To: "Liam R. E. Quin" <liam@fromoldbooks.org>
- Cc: Ian Jacobs <ij@w3.org>, Innovimax W3C <innovimax+w3c@gmail.com>, Adam Retter <adam@exist-db.org>, Team Community Process <team-community-process@w3.org>, public-expath@w3.org
+1 to what Liam says. In particular, Liam notes: In principle it could be a single group, but that isn't how it's been organised in the past, with different goals and different people taking the lead. I think this is an important point. By nature, something like EXSLT can be more hospitable to minority interests than the group responsible for the QT specs can be. In specs like XSLT and XQuery there is usually a rather high bar for features that will be of use to some but not all users, and a high bar for making features optional. In EXSLT, every extension is by nature optional, and if a small fraction of the population may benefit from agreeing on the form of a particular extension, it may make sense to define that extension in EXSTL even though that extension would not have a prayer of being adopted by the QT4 WG. Having two distinct groups helps make the difference in their goals clearer. If the ongoing cost to W3C of a quiescent community group is high, then the cost/benefit ratio may be unpropitious. But the alternative costs are potentially also high: the cost of later starting a new group from scratch to continue the work of the old discontinued group, or the (intangible, I guess) cost to W3C of people deciding that W3C is not where certain work is going to be done. Weren't community groups sold at the outset as a way for W3C to support some kinds of technical work at minimal cost to the consortium? If the ongoing cost to W3C of quiet groups is high enough to merit Ian's attention, I wonder what went wrong with the original idea. (Or possibly how I managed to misunderstand the original idea.) Michael Sperberg-McQueen "Liam R. E. Quin" <liam@fromoldbooks.org> writes: > On Mon, 2024-07-01 at 08:36 -0500, Ian Jacobs wrote: >> >> I’d like to focus on the question: what value is the group providing? >> >> If the group is providing value, then it would be great to understand >> what that is, and to communicate to more people who might also want >> to participate. > > The EXPath specs are widely implemented and are used not only in XSLT > but in raw XPath, in XQuery implementations, and elsewhere. > > The CG is quiescent right now because there hasn't been any change in > XPath or XSLT since the 2016/2017 W3C recommendations. > > The documents are consulted (you're more likely to know how often than > i, but i know they are used). > > It’s my expectation that we will start to see updates, probably later > this year or early next year would be my guess. > > The work is separate from XSLT and XQuery and base XPath; however, we > do have a single group (qt4) for work on XSLT and XQuery and XPath. So > there are really only two groups, not lots, for this work. There’s a > lower threshhold for the expath work, as not all implementations are > required to support it. > > In principle it could be a single group, but that isn't how it's been > organised in the past, with different goals and different people taking > the lead. > > If they were combined (and documents could still be updated in both of > course), would EXPath become some sort of subgroup? > > I would not be surprised to see expath membership increase when there's > new activity. The group exists to fill in gaps needed by users but that > are not filled in by the main specifications, for a number of reasons, > in some cases because of a lack of consensus. So combining the groups > might actually block expath from going forward. > > Sorry for a long answer; i hope that's clearer. -- C. M. Sperberg-McQueen Black Mesa Technologies LLC http://blackmesatech.com
Received on Friday, 5 July 2024 15:20:06 UTC