- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 06 Sep 2022 17:38:31 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m27d2gfod7.fsf@saxonica.com>
Draft minutes of the QT4 CG call on 6 September 2022.
* Minutes
** Administrivia
*** Roll call
+ [X] Anthony Bufort (AB)
+ [X] Reece Dunn (RD)
+ [X] Christian Grün (CG)
+ [X] Joel Kalvesmaki (JK)
+ [X] Michael Kay (MK)
+ [X] John Lumley (JL)
+ [X] Dimitre Novatchev (DN)
+ [X] Ed Porter (EP)
+ [X] Liam Quin[:45-] (LQ)
+ [X] C. M. Sperberg-McQueen (CSM)
+ [X] Norm Tovey-Walsh (NW)
+ [X] Bethan Tovey-Walsh (BTW)
*** Appoint chair and scribe for meeting
Norm volunteers, no objections.
*** Hello and welcome
Round-table and introductions.
**** Review of where we are
+ W3C Community group, https://www.w3.org/community/xslt-40/
+ GitHub organization, https://github.com/qt4cg/
+ Website, https://qt4cg.org/
+ XPath-NG channel on XML slack as a back-channel during the calls,
for those that find a back channel useful.
**** Process and plan
+ Weekly telcons
+ drafts published at qt4cg.org via automation on the GitHub
repository.
The current charter for the CG is a bit out-of-date. We might wish to
adopt something more up-to-date and concrete.
NW made a proposal in email,
https://lists.w3.org/Archives/Public/public-xslt-40/2022Sep/0001.html
The discussion that follows is, at least in part, about reactions to
that proposal.
+ NW: I think we should try to continue that discussion in email for another week.
+ CSM: What about community group sunsetting?
+ NW: I don’t think there’s an expiration date on community groups.
+ DN: I asked some clarification questions about the document in email.
+ RD: Can we make changes to all of the specs? For example,
+ editorial changes to the union syntax
+ adding unions to the hiearchy of types, etc.
+ DN: We shouldn’t exclude any kinds of changes; we might want to extend the data model.
+ One of my proposals is to allow any items as values of keys in maps
+ MK: We’ll certainly need to make editorial changes to all the specs
+ My experience is that if you add a fundamental new type, like
arrays, it’s three year’s work to follow that through
+ I’d like to establish a baseline to try to steer clear of those
kinds of changes if we can
+ I want to keep the thing bounded
+ CSM: Just to clarify, we can publish new documents, describing new
things, but we can’t change the existing specs on the TR page.
+ NW: That’s true.
+ DN: Who are the implementors?
+ NW: Saxonica
+ CG: BaseX
+ RD: I’m implementing the syntax changes in the XQuery plugin for IntelliJ
+ What about eXist? (Maybe Adam Retter? Unfortunately, he couldn’t make this time slot.)
+ DN: Are there any other XSLT 4.0 implementors.
+ Mike observes that Altova often implements things after they’re
specified, but doesn’t participate in standards work. published.
+ Maybe MarkLogic?
+ Sometimes implementors come along later
+ BT: I thought DN was wondering who the implementors of XSLT 4.0 on the group are
Some additional discussion of implementors. As a practical matter, it
appears that Saxonica is the only XSLT 4.0 implementor particpating
today.
Among the opinions variously expressed:
+ If there’s only one implementor, it might give the appearance that
the specification was designed for that implementor.
+ Unbounded scope for change runs the risk of having the process
become an academic exercise not grounded in implementation.
+ General agreement that it would be nice if there more implementors
participating.
+ As a matter of fact, implementing even XSLT 3 is a big effort.
+ On the one hand, it would be nice if there were other
implementations besides Saxon, but on the other, some open source
developers have expressed the opinion that there’s no reason for
them to implement it because Saxon is so nice.
+ Keeping implementors in check is valuable too. Implementors aren’t
the only readers that can give incredibly valuable technical
feedback and criticism.
+ The number of implementations of a given language tends to decline
over time, that’s true across all programming languages.
+ Some things, like the number of implementors are just facts. Maybe
we shouldn’t get too worked up about that issue unless or until it
becomes a problem.
+ Maybe we should soften the proposed language so that it’s about
expression of a rationale rather than veto.
+ DN proposes that one concrete step we could take towards making the
specs easier to implement, and perhaps thereby encouraging
implementors, would be to make the specifications much more modular.
They would be smaller and easier to read and would allow
implementors to focus on the parts that are important to their use
cases.
+ MK: It’s very difficult to get right. What I want to avoid is the
situation that we had with 2.0 and 3.0 where, for example, in 2.0
schema awareness took 7 years and in 3.0 streaming took 10 years. I
don’t want to embark on something that turns out to be an enormous
amount of work to complete especially if it turns out that, in
practice, relatively few users use it!
+ NW proposes that we take this to email for a week.
+ JL: Coming back to the other topic I wanted to ask about:
deriviative documents. What’s the status of those with respect to
copyright and derivative works?
+ NW: Given that the community group is hosted by the W3C, I don’t
think it’s a problem. The XProc 3.0 CG started with the XProc 1.0
Recommendation and no one has ever blinked at it.
+ LQ: I agree
**** Appointment of permanent chair and editor
NW volunteers to chair, moves to make MK the editor.
+ MK: The task of editing might prove to benefit from having multiple
folks taking part and taking over different parts. For eample, the
actual mechanics of editing the grammar are tricky. It’s good to have
an expert doing that job. I invite everyone to consider where they’d
be willing to volunteer to do part of the job!
+ RD: Can we take advantage of pull requests to make the process easier.
+ NW: Absolutely! That’s worked really well for the XProc CG and I
really hope we can take advantage of it.
+ DN: I want to say i’m perfectly happy with the proposed chair and
editors. But, again, from the outside this might not look very good.
I would like to propose CMS or LQ.
+ CMS: I don’t believe that I currently have the bandwidth. I’m
reluctant to say yes. In a few months I may change my mind. If we
are concerned in part about public perception, then I’d be happy to
be a co-chair.
+ LQ: I have already heard from people that XSLT 4.0 is a Saxonica
thing. They don’t feel comfrontable coming to Saxonica to say that,
so we won’t see them here. Right now, I’m completely overwhelmed
with work, but that could change.
+ BT: Would it make sense for CSM and NW to be listed as co-chairs now
and for us to review this later on if there seems to be trouble?
+ CMS: Can we let it season for a week first.
+ NW: Sure. We can revisit this next week.
* Any other business
** How are we going to select agenda items?
+ MK: I think we should start with low-hanging fruit. If we build up
speed and momentum that’ll help us establish working methods.
+ NW: Makes sens to me. It’s an opportunity to practice the pull
requests and other mechanics. We’ll also need to triage the bug list
at some point.
+ RD: Can we label them? Bug, editorial, feature, etc.? Focus
initially on existing things currently in the spec, work on
ratifying those and then moving on to other things?
+ JL: One thing that’s a ray of hope is that there are no big ticket
items in the cards at the moment, nothing as big as packaging,
streaming, etc.
+ MK: when we started packaging, we didn’t know how big it was going
to be!
* Adjourned
Be seeing you,
norm
--
Norman Tovey-Walsh <ndw@nwalsh.com>
https://nwalsh.com/
> Curiosity never killed anything except maybe a few hours.
Received on Tuesday, 6 September 2022 16:40:25 UTC