QT4 CG Meeting Minutes, 2022-09-06

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

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,
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

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
+ 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

+ 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,

Norman Tovey-Walsh <ndw@nwalsh.com>

> Curiosity never killed anything except maybe a few hours.

Received on Tuesday, 6 September 2022 16:40:25 UTC