QT4 CG Meeting 001 Minutes 2022-09-06

Table of Contents

Minutes

Approved emailed minutes on 13 September.

1. Administrivia

1.1. 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)

1.2. Appoint chair and scribe for meeting

Norm volunteers, no objections.

1.3. Hello and welcome

Round-table and introductions.

1.4. Review of where we are

1.5. 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

1.5.1. 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.

2. Any other business

2.1. 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!

3. Adjourned