- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 26 Sep 2023 17:35:19 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m24jjguc2g.fsf@saxonica.com>
Hello folks,
Here are the draft minutes from today:
https://qt4cg.org/meeting/minutes/2023/09-26.html
QT4 CG Meeting 047 Minutes 2023-09-26
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/8]
* [3]1. Administrivia
+ [4]1.1. Roll call [10/11]
+ [5]1.2. Accept the agenda
o [6]1.2.1. Status so far...
+ [7]1.3. Approve minutes of the previous meeting
+ [8]1.4. Next meeting
+ [9]1.5. Review of open action items [0/7]
+ [10]1.6. Review of open pull requests and issues related to
XSLT
o [11]1.6.1. Blocked
o [12]1.6.2. Substantive PRs
o [13]1.6.3. XSLT-related issues
* [14]2. Technical Agenda
+ [15]2.1. PR #718: Add on-no-match="shallow-copy-all"
+ [16]2.2. PR #717: 211: add capturing accumulators to XSLT
+ [17]2.3. PR #674: 663: Describe how calls to xsl:original with
keywords work
+ [18]2.4. PR #650: 649: fix an xsl:fallback problem
+ [19]2.5. Issue #571: XSLT: xsl:for-each-group/@break-when
* [20]3. Any other business?
* [21]4. Adjourned
[22]Agenda index / [23]QT4CG.org / [24]Dashboard / [25]GH Issues /
[26]GH Pull Requests
Draft Minutes
Summary of new and continuing actions [0/8]
* [ ] QT4CG-029-07: NW to open the next discussion of #397 with a
demo from DN
+ See PR [27]#449. Discussion planned for meeting 048, 3 October
2023.
* [ ] QT4CG-045-02: RD to address comments on HTML namespaces in
another PR
* [ ] QT4CG-046-01: MK to continue the work on #129 for the other
specs (we accepted #703)
* [ ] QT4CG-046-02: RD to draft the specification changes to allow
record(*)
* [ ] QT4CG-046-03: MK to roll back the changes related to default
namespaces for elments and types (issue #372)
* [ ] QT4CG-046-04: CG to flesh out changes related to annotations in
other parts of the specs
* [ ] QT4CG-046-05: NW to updated parse-uri to use decode-from-uri
(issue #566)
* [ ] QT4CG-047-01: MK to make a PR that renames break-when to
split-when
1. Administrivia
1.1. Roll call [10/11]
Regrets: CG.
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [ ] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] John Lumley (JL)
* [X] Dimitre Novatchev (DN)
* [X] Wendell Piez (WP)
* [X] Ed Porter (EP)
* [X] C. M. Sperberg-McQueen (MSM)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [28]the agenda.
Accepted.
1.2.1. Status so far...
issues-open-2023-09-26.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2023-09-26.png
Figure 2: Open issues by specification
issues-by-type-2023-09-26.png
Figure 3: Open issues by type
1.3. Approve minutes of the previous meeting
Proposal: Accept [29]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting [30]is scheduled for Tuesday, 3 October 2023.
Regrets: NW, MSM to chair. WP possibly.
JL gives regrets for 10, 17 October.
1.5. Review of open action items [0/7]
* [ ] QT4CG-029-07: NW to open the next discussion of #397 with a
demo from DN
+ See PR [31]#449. Discussion planned for meeting 048, 3 October
2023.
* [ ] QT4CG-045-02: RD to address comments on HTML namespaces in
another PR
* [ ] QT4CG-046-01: MK to continue the work on #129 for the other
specs (we accepted #703)
* [ ] QT4CG-046-02: RD to draft the specification changes to allow
record(*)
* [ ] QT4CG-046-03: MK to roll back the changes related to default
namespaces for elments and types (issue #372)
* [ ] QT4CG-046-04: CG to flesh out changes related to annotations in
other parts of the specs
* [ ] QT4CG-046-05: NW to updated parse-uri to use decode-from-uri
(issue #566)
1.6. Review of open pull requests and issues related to XSLT
1.6.1. Blocked
The following PRs are open but have merge conflicts or comments which
suggest they aren't ready for action.
* PR [32]#470: 369 add fixed-prefixes attribute in XSLT
* PR [33]#412: 409, QT4CG-027-01: xsl:next-match
1.6.2. Substantive PRs
* PR [34]#718: Add on-no-match="shallow-copy-all"
* PR [35]#717: 211: add capturing accumulators to XSLT
* PR [36]#674: 663: Describe how calls to xsl:original with keywords
work
* PR [37]#650: 649: fix an xsl:fallback problem
1.6.3. XSLT-related issues
These issues identify the XSLT-focused changes that have been made to
the specifications but which have not been established by the community
group as the status quo.
* Issue [38]#571: XSLT: xsl:for-each-group/@break-when
* Issue [39]#233: Declare the result type of a mode, via @as
* Issue [40]#172: Record Tests Feature
* Issue [41]#169: Handling of duplicate keys in xsl:map Enhancement
* Issue [42]#168: XSLT Extension Instructions invoking Named
Templates
2. Technical Agenda
2.1. PR #718: Add on-no-match="shallow-copy-all"
See #[43]718.
MK reviews the PR.
* MK: This is attempting to give you the same kind of recursive
decent technology for JSON that you get for XML. It applies
templates to the constituents of a map or an array.
+ ... Unfortunately, the current shallow-copy mode doesn't
shallow copy arrays and maps, it deep copies them.
* MSM: I'm assuming that it applies templates to the constituents and
builds an array or map out of them.
* MK: Yes. Technically, it's a bottom-up model.
* MK: There's a new on-no-match role, "shallow-copy-all". I was going
to add "shallow-skip-all", but I couldn't find any way to make it
useful.
+ ... You can't sensibly remove intermediate levels from maps or
arrays, so I gave up on the attempt.
* MK: I should confess that we need to work through a large number of
use cases to make sure we have all functionality we need.
* DN: What's the difference between shallow-copy and
shallow-copy-all?
* MK: On a map or array, shallow-copy does a deep copy.
* DN: Maybe the names could be better?
* MK: If you can think of a better name, please suggest it.
Some discussion about what "shallow-copy" doesn't do the right thing.
Basically, the way it's defined isn't useful and we can't redefine that
now.
If you use shallow-copy-all and then do nothing with all the matches,
you'll get the same output.
* JL: Is it a top-down or a bottom-up process? Are you going to end
up with empty maps and arrays which would be case when you're going
top down. It doesn't happen in node cases because we have empty
documents that don't contribute anything.
* MK: You can end up with empty maps and arrays. That's a case where
fine-tuning might be possible.
* DN: For names, how about deep-shallow-copy or
detailed-shallow-copy?
We'll come back to names after we've looked at the substance.
* MK: We add 6.8.4, describing the built-in templates for
shallow-copy-all.
+ ... Effects on anything other than a map or array is
equivalent to shallow-copy.
MK walks through the informal description in the prose of 6.8.4.
* MK: For maps, the processing is different depending on whether the
map has two or more entries (so that the recursion terminates).
* DN: When processing maps, it seems like the question of ordering is
relevant. We don't know anything about the order.
* MK: It would work perfectly well if you processed them in parallel.
Your processing all the entries in the input map to produce entries
in the output map. Order is irrelevant.
* DN: Is this specified precisely?
* MK: I think it's implicit in the equivalence rule.
* DN: I think it should be said precisely.
* MK: I'll add a note.
* RD: Wouldn't it make sense to also process the key? There are use
cases where you want to filter out entries by specific keys. Or
rename keys if you're mapping from one JSON format to another.
* MK: It's the copy everything else case, you define rules for things
that you want to handle specifically, and everything else gets
thrown at the default case. The default is copy it regardless. You
could say "throw the key at a template rule" but then you'd need to
have a separate mode and that would get quite complicated.
RD describes a use case where keys are removed or renamed.
MK returns to the non-diff version for a better view of the "pre" text.
* MK: The example simply deletes some entries from the JSON
structure. The prose explains why this example works.
* JL: When we manuall build maps, we can specify multiple key
conflict resolution strategies. Can you do that here?
* MK: I think you'd have to override the template rule at the top
level to have a different on-duplicates clause.
* JL: You couldn't do it globally?
* RD: You could have a rule that matches any map and does the
on-duplicates behavior.
* MK: It's a good question.
* JL: Wouldn't that impede using next-match?
* MK: It's a good question, we should see about a use case to see how
it behaves.
* MSM: Two questions, to make sure I'm following. The sequence of
entries when we decompose the map into a sequence of maps. That
function is nondeterministic, so there's no guarantee that it'll
produce the same result twice in a row.
* MK: Yes.
* MSM: And I think it's already been suggested and agreed to add a
note that the sequence cannot effect the result.
+ ... I'm trying to understand the filtering case. What template
do I write if I want to suppress an entry for key "X" entirely
and what template I write if I want "X" to return the empty
sequence.
* MK: To suppress something entirely, just match it and produce no
output.
+ ... If you want to return an empty one, add an xsl:map-entry
that returns something different.
* DN: I think that RD raised an important question. I can imagine
constructing a template that matches a value of a particular key,
"X". It should be allowed to override something in the built-in
template.
+ ... It seems like we need finer grained detail in drilling
down.
* MK: I think this is an example where we need to try this out on
particular use cases and it's going to take a little time to work
those through. Some will turn out easy, some more difficult, some
may suggest enhancements. I'm reasonably comfortable that we have
the basics, but it needs testing against real use cases.
Some discussion of what additional use cases we need.
Some discussion of the difference between variables and templates wrt
sequence constructors.
* JL: Long ago, I worked on converting modes in XSLT 3.0 to modes in
XSLT 2.0. It seems like something like that could be done here.
* MK: In a sense this was inspired by work that I did on real
transformations involving maps.
MK repeats the observation that we may see further refinement but this
is a good baseline.
Proposal: accept this PR.
Accepted.
2.2. PR #717: 211: add capturing accumulators to XSLT
See #[44]717.
* MK: This is an extension that I implemented in Saxon that has
proved very popular. This adds it to the specification. I thought
at one point I could add it without any new syntax, just removing
some streamability restrictions.
+ ... Section 18.2.9, Capturing accumulators
+ ... The current specification says that the rules have to be
motionless. So if you want to capture the glossary entries at
the end of the chapter, you have to capture the text nodes,
not the elements because the elements would look at a range of
nodes.
+ ... What this says is that the phase=end rule can capture the
whole value of an element as the value of the accumulator.
+ ... That means you have to know at the start that this is a
capturing accumulator.
* JL: This implies effectively that you're doing a copy between the
start and end phases.
* MK: It's defined as a snapshot, not a copy. You get the whole
subtrue.
Some discussion about whether a diagram would be nice here.
Proposal: accept this PR.
Accepted.
2.3. PR #674: 663: Describe how calls to xsl:original with keywords work
See #[45]674.
* MK: This is a very minor little extension. It fills in an omission.
It says, if you call xsl:original with keyword arguments, this
tells you what keywords are used. The choice is arbitrary, we just
had to be explicit.
Proposal: accept this PR.
Accepted.
2.4. PR #650: 649: fix an xsl:fallback problem
See #[46]650.
* MK: This fixes a bug in fowards-compatiblity mode.
+ ... If you're using something like xsl:array, a 4.0 feature,
you can say xsl:fallback to do the fallback behavior for an
older processor.
+ ... But it'll execute the fallback in forwards-compatibility
mode, so it'll ignore things it doesn't understand.
+ ... That's not what you want.
+ ... This changes those rules to say that you raise an error.
We can't fix this retrospectively, but we might encourage
implementations to do it anyway.
* RD: Fallback only applies to the current template because if you
call apply-templates, you could potentially be calling 4.0
functionality from that.
* MK: Forwards compatibility mode applies at the level of the
instruction. You can define fallback for an individual instruction.
* RD: Is there a way to know what version you're falling back to?
* MK: That's determined the processor you're using. If it's a 3.0
processor, it falls back to 3.0 code.
* RD: If you're in an editor or an IDE, and you add a fallback, and
start using 4.0 constructs, then the behavior of that is processor
dependent?
* MK: In principle you can put a version attribute on the
xsl:fallback element...
Some discussion of how often this is actually used and why it isn't
used more. It's hard to get correct retrospectively, but this is a
small fix we can make.
* WP: If it's not widely be used, maybe we should deprecate the
feature.
* MK: Given that fallback sort of represented a promise in older
versions of the specification, it would be a bit hard to reneg on
that promise.
* MSM: Yes. What MK just said. But also, I'd like to say comparing
the experiences of the XSLT working group over time and those of
other working groups, I'd say whether it was implemented or not, it
was a huge success because it allowed the WG to develop 2.0 and
3.0. Not having any fallback story is a very good way to ensure
that there will be people in the working group saying "you can't
change that."
* WP: I find that convincing. But we have a lot of things now.
* RD: There's also vendor extensions to consider here. Processors
like MarkLogic define their own XSLT extensions and fallback
applies to those.
* MK: The notorious example is the DocBook 1.0 stylesheets which
tried to support many processors.
Proposal: accept this PR.
Accepted.
2.5. Issue #571: XSLT: xsl:for-each-group/@break-when
See #[47]571.
* MK: This is in the spec, but needs reviewing.
+ ... The issue has triggered some discussion including a
proposal to change the name.
* NW: I think JK is exactly right and I like the proposed name.
MK walks us through the specification.
* MK: The examples in the spec tell the story, it's a new way of
deciding where a new group begins. Your choice can be based on
what's in the group or what's going to be next.
+ ... It subsumes a lot of the current capability and adds more.
* JL: In your examples, you have examples of things that could be
expressed as group-ending-with and group-adjacent, are any of them
always possible with break-when?
* MK: I think it's probably always possible, but maybe not always
convenient.
* JL: The example of string lengths implies that there are parallels
in iterate.
* MK: Yes, if you had to do that currently, you'd use xsl:iterate.
Further discussion of the extent to which break-when subsumes the other
options.
Some discussion of the name of the attribute. Apparent consensus that
split-when works.
Proposal: this change is accepted as the consensus position; close the
issue.
Accepted.
ACTION QT4CG-047-01: MK to make a PR that renames break-when to
split-when
3. Any other business?
NW: We still have a slate of XSLT issues, let's try to do this a little
more often until we get them squared away.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2023/09-26.html#minutes
2. https://qt4cg.org/meeting/minutes/2023/09-26.html#new-actions
3. https://qt4cg.org/meeting/minutes/2023/09-26.html#administrivia
4. https://qt4cg.org/meeting/minutes/2023/09-26.html#roll-call
5. https://qt4cg.org/meeting/minutes/2023/09-26.html#agenda
6. https://qt4cg.org/meeting/minutes/2023/09-26.html#so-far
7. https://qt4cg.org/meeting/minutes/2023/09-26.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2023/09-26.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2023/09-26.html#open-actions
10. https://qt4cg.org/meeting/minutes/2023/09-26.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2023/09-26.html#blocked
12. https://qt4cg.org/meeting/minutes/2023/09-26.html#xslt-focused
13. https://qt4cg.org/meeting/minutes/2023/09-26.html#xslt-related-issues
14. https://qt4cg.org/meeting/minutes/2023/09-26.html#technical-agenda
15. https://qt4cg.org/meeting/minutes/2023/09-26.html#pr-718
16. https://qt4cg.org/meeting/minutes/2023/09-26.html#pr-717
17. https://qt4cg.org/meeting/minutes/2023/09-26.html#pr-674
18. https://qt4cg.org/meeting/minutes/2023/09-26.html#pr-650
19. https://qt4cg.org/meeting/minutes/2023/09-26.html#iss-571
20. https://qt4cg.org/meeting/minutes/2023/09-26.html#any-other-business
21. https://qt4cg.org/meeting/minutes/2023/09-26.html#adjourned
22. https://qt4cg.org/meeting/minutes/
23. https://qt4cg.org/
24. https://qt4cg.org/dashboard
25. https://github.com/qt4cg/qtspecs/issues
26. https://github.com/qt4cg/qtspecs/pulls
27. https://qt4cg.org/dashboard/#pr-449
28. https://qt4cg.org/meeting/agenda/2023/09-26.html
29. https://qt4cg.org/meeting/minutes/2023/09-19.html
30. https://qt4cg.org/meeting/agenda/2023/10-03.html
31. https://qt4cg.org/dashboard/#pr-449
32. https://qt4cg.org/dashboard/#pr-470
33. https://qt4cg.org/dashboard/#pr-412
34. https://qt4cg.org/dashboard/#pr-718
35. https://qt4cg.org/dashboard/#pr-717
36. https://qt4cg.org/dashboard/#pr-674
37. https://qt4cg.org/dashboard/#pr-650
38. https://github.com/qt4cg/qtspecs/issues/571
39. https://github.com/qt4cg/qtspecs/issues/233
40. https://github.com/qt4cg/qtspecs/issues/172
41. https://github.com/qt4cg/qtspecs/issues/169
42. https://github.com/qt4cg/qtspecs/issues/168
43. https://qt4cg.org/dashboard/#pr-718
44. https://qt4cg.org/dashboard/#pr-717
45. https://qt4cg.org/dashboard/#pr-674
46. https://qt4cg.org/dashboard/#pr-650
47. https://github.com/qt4cg/qtspecs/issues/571
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 26 September 2023 16:36:02 UTC