- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 18 Jun 2024 17:47:52 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m2plsep58n.fsf@saxonica.com>
Here’s are the draft minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2024/06-18.html
QT4 CG Meeting 082 Minutes 2024-06-18
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [1/18]
* [3]1. Administrivia
+ [4]1.1. Roll call [11/12]
+ [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 [15/18]
+ [10]1.6. Review of open pull requests and issues
o [11]1.6.1. Substantive PRs
o [12]1.6.2. Proposed for V4.0
* [13]2. Technical Agenda
+ [14]2.1. HTML 5 template element content
+ [15]2.2. PR #1280: 1267 fn:apply contradictions
+ [16]2.3. PR #1279: 1278 - line endings in unparsed-text-lines
+ [17]2.4. PR #1276: QT4CG-081-03 parse-xml-[fragment]: $options
should be optional
+ [18]2.5. PR #1270: QT4CG-081-01 Add cross refererence from
fn:round-half-to-even
+ [19]2.6. PR #1268: QT4CG-077-03 Add note on document order
across documents
+ [20]2.7. PR #1264: 1245 Correct properties of format-DT
function family
+ [21]2.8. PR #1275: 1274 Further rounding modes
* [22]3. Any other business
* [23]4. Adjourned
[24]Meeting index / [25]QT4CG.org / [26]Dashboard / [27]GH Issues /
[28]GH Pull Requests
Draft Minutes
Summary of new and continuing actions [1/18]
* [ ] QT4CG-079-01: WP to seek expert advice on hashing functions.
* [ ] QT4CG-080-05: NW to add absolute property to the parse-uri
output
* [ ] QT4CG-080-07: NW to update the build instructions in the README
* [ ] QT4CG-082-01: JLO to raise an issue about what to do when
validation is requested but not possible.
* [ ] QT4CG-082-02: DN to work with MK to come to agreement on the
fn:ranks proposal
1. Administrivia
1.1. Roll call [11/12]
CG gives regrets.
* [X] Reece Dunn (RD) [x:10-]
* [X] Sasha Firsov (SF)
* [ ] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] Juri Leino (JLO)
* [X] John Lumley (JLY)
* [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 [29]the agenda.
Accepted.
1.2.1. Status so far...
issues-open-2024-06-18.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2024-06-18.png
Figure 2: Open issues by specification
issues-by-type-2024-06-18.png
Figure 3: Open issues by type
1.3. Approve minutes of the previous meeting
Proposal: Accept [30]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
This next meeting is planned for 25 June.
CG gives regrets for two weeks.
1.5. Review of open action items [15/18]
* [X] QT4CG-063-06: MK to consider refactoring the declare item type
syntax to something like declare record
* [X] QT4CG-077-04: MK to review inconsistencies discovered in review
of #1117
* [X] QT4CG-078-01: MK to make the default for normalize-newlines
backwards compatible.
* [ ] QT4CG-079-01: WP to seek expert advice on hashing functions.
* [X] QT4CG-080-01: NW to add what the DocBook stylesheets do for
this function
* [X] QT4CG-080-02: NW to fix issue classification so PR #1181 isn't
misclassified as an XSLT issue
* [X] QT4CG-080-03: MK to make a separate issue for @as on
xsl:value-of
* [X] QT4CG-080-04: NW to revise p:invisible-xml
* [ ] QT4CG-080-05: NW to add absolute property to the parse-uri
output
* [X] QT4CG-080-06: NW to investigate the cross-spec reference errors
in the build
* [ ] QT4CG-080-07: NW to update the build instructions in the README
* [X] QT4CG-080-08: MK to work out what happened to his next-match PR
* [X] QT4CG-080-09: MK to address comments made on PR #832
* [X] QT4CG-081-01: MK to update fn:round-to-even to point to
fn:round
* [X] QT4CG-081-02: NW to make an issue about how grammar productions
should be identified
* [X] QT4CG-081-03: MK to make the options parameter optional in
fn:parse-xml and fn:parse-xml-fragment
* [X] QT4CG-081-04: NW to update the function signature of
fn:invisible-xml
* [X] QT4CG-081-04: NW to describe why the grammar option can be
empty on fn:invisible-xml
MK reports creating issues for his actions, so the actions are marked
as completed.
1.6. Review of open pull requests and issues
1.6.1. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [31]#1280: 1267 fn:apply contradictions
* PR [32]#1279: 1278 - line endings in unparsed-text-lines
* PR [33]#1276: QT4CG-081-03 parse-xml-[fragment]: $options should be
optional
* PR [34]#1275: 1274 Further rounding modes
* PR [35]#1270: QT4CG-081-01 Add cross refererence from
fn:round-half-to-even
* PR [36]#1268: QT4CG-077-03 Add note on document order across
documents
* PR [37]#1266: 1158 Add array mapping operator
* PR [38]#1265: 1161 Further revision of document-uri constraints
* PR [39]#1264: 1245 Correct properties of format-DT function family
* PR [40]#1262: 1160 Add collation-available() function
* PR [41]#1254: 729 Add rules for use of xsi:schemaLocation during
validation
* PR [42]#1244: 566-partial Rewrite parse-uri
* PR [43]#1228: - Adding the BLAKE3 hashing algorithm to fn:hash
* PR [44]#1209: 1183 Add transient mode and the transient{}
expression
* PR [45]#1185: 1179 array:values, map:values -> array:get, map:get
1.6.2. Proposed for V4.0
The following issues are labled "proposed for V4.0".
* Issue [46]#1225: Generalization of Deep Updates
* Issue [47]#1069: fn:ucd
* Issue [48]#938: Canonical serialization
* Issue [49]#850: fn:parse-html: Finalization
* Issue [50]#755: Expression for binding the Context Value
* Issue [51]#689: fn:stack-trace: keep, drop, replace with
$err:stack-trace ?
* Issue [52]#657: User-defined functions in main modules without
`local` prefix
* Issue [53]#576: JSON serialization: Sequences, INF/NaN, function
items
* Issue [54]#501: Error handling: Rethrow errors; finally block
* Issue [55]#150: fn:ranks: Produce all ranks in applying a function
on the items of a sequence
* Issue [56]#37: Support sequence, array, and map destructuring
declarations
* Issue [57]#31: Extend FLWOR expressions to maps
2. Technical Agenda
2.1. HTML 5 template element content
This is a follow-up from the face-to-face meeting, see [58]issue 75.
RD introduces the template element starting at
[59]https://html.spec.whatwg.org/multipage/scripting.html#the-template-
element
* RD: When the HTML parser parses the template element and adds it
into the DOM, it doesn't add the child elements as children of the
template, it constructs a document fragment and attaches that to
the content property of the HTML template DOM.
+ ... That's what element.content returns in JavaScript
+ ... It's a DocumentFragment(), a new node type in HTML5.
+ ... There's also a ShadowRoot for similar style document
fragments.
o ... The other shadow roots can only be constructed with
JavaScript
* RD: When you parse the HTML document, you get the HTML DOM but the
template doesn't have any child elements.
+ ... A document fragment isn't a document, it can have multiple
roots.
RD demonstrates a query in codepen.io/yoann-b/pen/jOLjjOP
* RD: The WHATWG defines two different behaviors for XSLT and XPath.
+ If you use XSLT, then the template element should behave as if
the content elements are child elements.
+ But if you're using XPath, then you don't.
* RD: That's why the HTML parse options has an
include-template-content option. It lets you control which behavior
you want when parsing the document.
+ ... That's also why the children accessor in the HTML DOM
section is complicated.
+ ... But we aren't supporting document fragments because they
aren't nodes in the XDM.
+ ... Can we add support for templates by adding a new XDM node
type?
* SF: It happens that content is only materialized at the moment of
attachment when the browser adds it to the DOM.
+ ... When we are working on the parser level, you're never
dealing with the HTML not the virtual, detatched DOM.
+ ... The template behavior is triggered when the content is
attached to the document.
+ ... I don't see any reason to handle the templates
differently. During the transformation, you don't want to
simulate what the browser does.
+ ... Perhaps in the future, there will be reuse for the
templates. So they aren't injected, they're reused during the
rendering.
* RD: If you're using an HTML5 compliant parser, it'll be using the
algorithm that handles templates. There are two modes: tokenization
(tag name and attribute parsing into a node name and attributes
blob) and then it runs the tree construction which builds the HTML
DOM.
* SF: Yes, when it does the attachment, that's when the different
behavior happens. But we're using XSLT before we're attaching to
the DOM.
+ In both cases, the attachment step happens on the browser
level, so I don't need it at the XSLT layer.
+ Once it's adopted by the original DOM, it's tranformed into
the fragment.
+ When we do the XSLT transformation, we're receiving the HTML
as a DOM tree, but this doesn't need to be "unwrapped". It
doesn't need to have the document fragments inside.
* JLY: Is the template trying to be like a def/use in SVG?
* RD: Yes, effectively.
* SF: It's not exactly reuse, you have to clone it.
* NW: I think there are two cases: can we generate templates, easy.
If we're loading an HTML5 DOM into an XDM, then we can punt to
"implementation defined" at some point.
* RD: I've tried to handle some of the DOM to XDM transformations in
the specification.
* MK: What is the gap in the current spec? What's the issue in the
status quo text?
* RD: The gap really is that the HTML DOM defines a document fragment
node and the XDM doesn't support that.
+ ... So we are currently working around that by dealing with
the templates by skipping the document fragment part and
treating it as if it doesn't exist.
* MK: And why is that a problem?
* SF: The original idea of having templates and document fragments is
isolation. The isolation is on many different layers: APIs, CSS,
DOMs, etc. That's done for the purpose. We can either ignore it, or
actually honor it.
+ ... It would be logical to have some support for templates.
They can be open or closed. If they're open, you can see
everything. If they're closed, they're a black box.
+ ... There is a plan to have even more open-styleable content.
This is on a per-template instance.
* JLO: I think that document fragments predate HTML 5. I haven't
found when they were introduced, but I've definitely had to deal
with them.
+ ... I don't see that we need to have this isolation. If
someone wants to deal with template elements in that way, then
they can.
* NW: Can we have a concrete use case?
* DN: I don't think the description of XPath and XSLT integration is
very clear. Does the browser call them? Which version will be used?
Can templates be nested? Maybe we need to get in contact with the
HTML authors to get on the same pages.
NW pulls his chair's hat down over his ears and draws this section to a
close.
2.2. PR #1280: 1267 fn:apply contradictions
See PR [60]#1280.
MK introduces the issue.
* MK: There are a few simple fixes, bu the substacne is in the
fn:apply function.
+ ... I've changed the spec to be clear that the size of the
array doesn't have to exactly match the number of arguments.
* JLO: I like this. I just fear that this has consequences that I
can't see. Ignoring excess arguments worries me.
* MK: It's making it consistent with dynamic function calls where
this already happens.
* DN: I know that we adopted the rule that a function can be called
with extra arguments that are ignored. Now I'm worried about it a
little bit. Doesn't this effect the type safety?
+ ... In JavaScript isn't this only allowed in callbacks?
+ ... Are we proposing to allow static function calls to have
additional arguments?
+ ... Maybe we need to be more careful about when this is
allowed?
+ ... Perhaps we can even add a keyword that signals functions
are allowed to have extra arguments.
* MK: I share some of the reservations, but I think fn:apply needs to
be made consistent with dynamic function calls.
* DN: I think we need to constrain this feature.
* MK: Would you like to raise a new issue on that?
* DN: I'm a little tired of having things going into the spec that I
didn't agree with.
Anyone in favor? Several thumbs up. Anyone opposed: DN expresses
reservations.
* JLY: We're not talking about static function excess arguments,
isn't that right?
* MK: No, this is only about dynamic function calls.
* DN: It's very easy to make a static function into a dynamic
function, just assign it to a variable.
Proposal: merge this PR.
Accepted.
2.3. PR #1279: 1278 - line endings in unparsed-text-lines
See PR [61]#1279.
* MK: This originated with CG. This PR attempts to address an issue
raised by CG.
* MK: Unparsed text lines should continue as they did in 3.1, always
treating CR/LF and newline as equivalent.
+ ... This removes the normalize newline option, reverting to
the 3.1 spec.
Proposal: accept this PR.
Accepted.
2.4. PR #1276: QT4CG-081-03 parse-xml-[fragment]: $options should be optional
See PR [62]#1276.
* MK: This one is extremely trivial. It just adds a question mark to
the options parameter so that an empty sequence is allowed.
* JLO: Last week we merged in the validation options. Are those
optional?
* MK: XSD validation is an optional feature. We should say what
happens if you are in a non-schema aware processor.
+ ... We ought to say the same thing for DTD validation. If you
can't validate raise an error.
* SF: There's a need for validation and schema capabilities; it would
be nice if we have a separate meeting about this. it touches very
many questions here. In the community and on the web, it's a
critical issue.
Proposal: accept this PR.
Accepted.
ACTION: QT4CG-082-01: JLO to raise an issue about what to do when
validation is requested but not possible.
2.5. PR #1270: QT4CG-081-01 Add cross refererence from fn:round-half-to-even
See PR [63]#1270.
* MK: This just adds a cross reference.
Proposal: accept this PR.
Accepted.
2.6. PR #1268: QT4CG-077-03 Add note on document order across documents
See PR [64]#1268.
* MK: This adds a note that was requested in discussion of another
proposal. It reinforces document order across documents.
Proposal: accept this PR.
Accepted.
2.7. PR #1264: 1245 Correct properties of format-DT function family
See PR [65]#1264.
* MK: This merely brings the text on properties up to date with the
spec. Several arguments now have defaults.
Proposal: accept this PR.
Accepted.
2.8. PR #1275: 1274 Further rounding modes
See PR [66]#1275.
* MK: The rounding mode names differed from the names that Java used.
That got me looking around, so now I'm proposing that we extend the
set of modes we offer.
MK summarizes the nine modes.
* MK: That full set of nine is offered on .NET, Java offers seven.
+ ... Java offers the capability to offer all nine.
+ ... You can support any of the modes by some combination of
changing the sign, rounding, etc.
Proposal: accept this PR.
Accepted.
3. Any other business
* DN: What happened to the action that MK and I had to come to a
resolution on fn:ranks?
* NW: I don't recall, apologies if that got accidentally dropped.
I'll put it back.
(On further investigation, the [67]minutes of meeting 079 say that "DN
will attempt to work with MK" but don't record an explicit action; the
scribe will add one now.)
ACTION: QT4CG-082-02: DN to work with MK to come to agreement on the
fn:ranks proposal
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2024/06-18.html#minutes
2. https://qt4cg.org/meeting/minutes/2024/06-18.html#new-actions
3. https://qt4cg.org/meeting/minutes/2024/06-18.html#administrivia
4. https://qt4cg.org/meeting/minutes/2024/06-18.html#roll-call
5. https://qt4cg.org/meeting/minutes/2024/06-18.html#agenda
6. https://qt4cg.org/meeting/minutes/2024/06-18.html#so-far
7. https://qt4cg.org/meeting/minutes/2024/06-18.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2024/06-18.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2024/06-18.html#open-actions
10. https://qt4cg.org/meeting/minutes/2024/06-18.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2024/06-18.html#substantive
12. https://qt4cg.org/meeting/minutes/2024/06-18.html#proposed-40
13. https://qt4cg.org/meeting/minutes/2024/06-18.html#technical-agenda
14. https://qt4cg.org/meeting/minutes/2024/06-18.html#h-BF98CA1E-7B5C-4D07-93C5-73D78AD45BFF
15. https://qt4cg.org/meeting/minutes/2024/06-18.html#pr-1280
16. https://qt4cg.org/meeting/minutes/2024/06-18.html#pr-1279
17. https://qt4cg.org/meeting/minutes/2024/06-18.html#pr-1276
18. https://qt4cg.org/meeting/minutes/2024/06-18.html#pr-1270
19. https://qt4cg.org/meeting/minutes/2024/06-18.html#pr-1268
20. https://qt4cg.org/meeting/minutes/2024/06-18.html#pr-1264
21. https://qt4cg.org/meeting/minutes/2024/06-18.html#pr-1275
22. https://qt4cg.org/meeting/minutes/2024/06-18.html#any-other-business
23. https://qt4cg.org/meeting/minutes/2024/06-18.html#adjourned
24. https://qt4cg.org/meeting/minutes/
25. https://qt4cg.org/
26. https://qt4cg.org/dashboard
27. https://github.com/qt4cg/qtspecs/issues
28. https://github.com/qt4cg/qtspecs/pulls
29. https://qt4cg.org/meeting/agenda/2024/06-18.html
30. https://qt4cg.org/meeting/minutes/2024/06-11.html
31. https://qt4cg.org/dashboard/#pr-1280
32. https://qt4cg.org/dashboard/#pr-1279
33. https://qt4cg.org/dashboard/#pr-1276
34. https://qt4cg.org/dashboard/#pr-1275
35. https://qt4cg.org/dashboard/#pr-1270
36. https://qt4cg.org/dashboard/#pr-1268
37. https://qt4cg.org/dashboard/#pr-1266
38. https://qt4cg.org/dashboard/#pr-1265
39. https://qt4cg.org/dashboard/#pr-1264
40. https://qt4cg.org/dashboard/#pr-1262
41. https://qt4cg.org/dashboard/#pr-1254
42. https://qt4cg.org/dashboard/#pr-1244
43. https://qt4cg.org/dashboard/#pr-1228
44. https://qt4cg.org/dashboard/#pr-1209
45. https://qt4cg.org/dashboard/#pr-1185
46. https://github.com/qt4cg/qtspecs/issues/1225
47. https://github.com/qt4cg/qtspecs/issues/1069
48. https://github.com/qt4cg/qtspecs/issues/938
49. https://github.com/qt4cg/qtspecs/issues/850
50. https://github.com/qt4cg/qtspecs/issues/755
51. https://github.com/qt4cg/qtspecs/issues/689
52. https://github.com/qt4cg/qtspecs/issues/657
53. https://github.com/qt4cg/qtspecs/issues/576
54. https://github.com/qt4cg/qtspecs/issues/501
55. https://github.com/qt4cg/qtspecs/issues/150
56. https://github.com/qt4cg/qtspecs/issues/37
57. https://github.com/qt4cg/qtspecs/issues/31
58. https://github.com/qt4cg/qtspecs/issues/75
59. https://html.spec.whatwg.org/multipage/scripting.html#the-template-element
60. https://qt4cg.org/dashboard/#pr-1280
61. https://qt4cg.org/dashboard/#pr-1279
62. https://qt4cg.org/dashboard/#pr-1276
63. https://qt4cg.org/dashboard/#pr-1270
64. https://qt4cg.org/dashboard/#pr-1268
65. https://qt4cg.org/dashboard/#pr-1264
66. https://qt4cg.org/dashboard/#pr-1275
67. https://qt4cg.org/meeting/minutes/2024/05-28.html#pr-1062
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 18 June 2024 16:48:08 UTC