QT4 CG Minutes 022, 14 February 2023 from Norm Tovey-Walsh on 2023-02-14 (public-xslt-40@w3.org from February 2023)

From: Norm Tovey-Walsh <norm@saxonica.com>
Date: Tue, 14 Feb 2023 17:21:47 +0000
To: public-xslt-40@w3.org
Message-ID: <m24jrokvq1.fsf@saxonica.com>

Hi folks,

Here are the draft minutes from today:

https://qt4cg.org/meeting/minutes/2023/02-14.html

QT4 CG Meeting 022 Minutes 2023-02-14

Table of Contents

* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/11]
* [3]1. Administrivia
+ [4]1.1. Roll call [10/14]
+ [5]1.2. Accept the agenda
+ [6]1.3. Approve minutes of the previous meeting
+ [7]1.4. Next meeting
+ [8]1.5. Review of open action items [0/6]
* [9]2. Technical Agenda
+ [10]2.1. PR #342: Meta elements
+ [11]2.2. PR #344: Issue 22, allow for/let to be repeated
+ [12]2.3. PR #320: Issue 98 - add options parameter to
fn:deep-equal
* [13]3. Any other business

Draft Minutes

Summary of new and continuing actions [0/11]

* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [ ] QT4CG-016-08: RD to clarify how namespace comparisons are
performed.
* [ ] QT4CG-021-01: NW to raise a PR addressing the points in issue
#307
* [ ] QT4CG-021-02: NW to check for deprecated URI features and add
options for them in fn:build-uri and fn:parse-uri
* [ ] QT4CG-021-03: RD to change must to will in DOM notes about
lowercase
* [ ] QT4CG-021-04: RD to revise and move the note about unrecognized
entities
* [ ] QT4CG-022-01: NW to investigate the illegible, dark blue
background color in serialization
* [ ] QT4CG-022-02: MK to add meta element selection to the list of
implementation-defined things in serialization
* [ ] QT4CG-022-03: MK to add a note about why multiple for and let
clauses were added to XPath
* [ ] QT4CG-022-04: MK to update the collation parameter on
fn:deep-equal to accept an empty sequence.
* [ ] QT4CG-022-05: MK to make sure that the option list in
fn:deep-equal is sorted lexicographically

1. Administrivia

1.1. Roll call [10/14]

Regrets: BTW
* [ ] Anthony (Tony) Bufort (AB)
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK) [:08-]
* [X] Michael Kay (MK)
* [X] John Lumley (JL)
* [X] Dimitre Novatchev (DN)
* [X] Ed Porter (EP)
* [ ] Liam Quin (LQ)
* [ ] Adam Retter
* [X] C. M. Sperberg-McQueen (MSM) [:06-]
* [ ] Bethan Tovey-Walsh (BTW)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.

1.2. Accept the agenda

Proposal: Accept [14]the agenda.

Accepted.

1.3. Approve minutes of the previous meeting

Proposal: Accept [15]the minutes of the previous meeting.

Accepted.

1.4. Next meeting

The next meeting [16]is scheduled for Tuesday, 21 February 2023.

Focus next week is XSLT; MK to help with the agenda.

Regrets: CG.

1.5. Review of open action items [0/6]

2. Technical Agenda

2.1. PR #342: Meta elements

See [17]pull request #342.
* MK: This is a bug from a Saxon user. The XHTML and HTML methods add
meta elements with a content type. HTML5 has introduced a new meta
element that doesn't have a content type, it just says charset=. If
we leave that one in the document, then you get an HTML validation
error.
+ ... Compliance with the serialization spec leads to invalid
HTML.
+ ... We fixed that in Saxon but now we're not compliant with
the serialization spec!
+ ... This PR proposes to update the serialization spec.

The changes are all in the serialization spec.
* MK: I did some housekeeping; I dropped all the diff markup from
before 3.1. Fixed a few whitespace issues.
* MK summarizes changes to section 4.
+ Some discussion of the change from "along with discarding" to
"possibly replacing"

ACTION QT4CG-022-01: NW to investigate the illegible, dark blue
background color in serialization
* MK discusses the changes in the beginning of 6.1.14.
* MK: Basically, this just licenses the new syntax if that's what you
choose to do.
* MK: It says pretty much the same thing for the HTML output method
in 7.4.13.
* DN: Seems ok, but I'm a little bit concerned about using "might"
and "may". That means it depends on the implementation.
* MK: Yes, that's a good point. I decided not to require that
implementations use the new behavior. Some implementations might
want to keep the old syntax.

Some discussion about the fact that it's an implementation-defined
result.
* NW: Perhaps making this a "should" requirement would help?

Some discussion of the fact that this only applies to the HTML5 output
method.
* MK: Should we even continue supporting versions of HTML before 5
anyway?
* MSM: For what it's worth, as a late adopter, I would be very
unhappy if we got rid of HTML4 because that's typically what I use.
+ ... I do kind of like the idea that if we're going to offer
this as a choice we should add it to the list of things that
are implementation-defined.

ACTION QT4CG-022-02: MK to add meta element selection to the list of
implementation-defined things in serialization
* SF: Depending on the situation, I'd be rendering in XHTML or HTML5.
That means I'd have to change how the meta tag differently in
different cases.
* MK: They're different output methods, but they share a lot in
common. The way the spec is structured, they have to be described
twice, but both methods take the same option.
+ ... I don't really understand how XHTML evolves as HTML5
changes.
* RD: Effectively, XHTML is an XML serialization of the HTML5 DOM.
* NW: That's what I thought.
* DN: I'm happy we discussed this. We must be aware that I find this
is a problem as a developer. I think if there are implementation
defined things, maybe we should provide an appendix that shows the
choices implementations made.

Some discussion of the appropriateness of adding this to the
specification. The Schema WG did not find the process of trying to
maintain this kind of thing easy or satisfactory.

DN remains concerned that there should be some place where the
implementation defined features for all the implementations can be
recorded.
* MK: Are you volunteering?
* DN: I don't have much experience, but maybe.

Proposal: Accept this PR

Accepted.

2.2. PR #344: Issue 22, allow for/let to be repeated

See [18]pull request #344.
* MK: I think this was originally raised by RD. The only question
here is how far to go. I chose not to go very far. I changed things
so that let and for can be repeated but not mixed.

MK shares the XPath spec for review.
* MK: SimpleForClause allows the keyword "for" as an alternative to
"," which makes it look more like an XQuery FLOWR expression with
multiple "for"s
+ ... The spec describes how the "for"s are syntactic sugar.
* MK: We do the same thing for let expressions in SimpleLetClause.
+ ... This doesn't preclude going further, but it's a starting
point.
* DN: Who needs this? We have the "," why do we need repeated "for"
or "let"?
* RD: It's a preference thing; if you're copying code from XQuery
where you've used multiple fors or lets, or if you have an XQuery
background, it will be what's familiar.
+ ... Kind of like how many languages support multiple variable
declarations by commas or repeated specifications. (int x; int
y; int j; vs. int x,y,j;)
* DN: Then maybe the prose should explain that.
* MSM: I'm kind of torn; MK has probably hit something of a sweet
spot here, precisely because for/let and the "," are synonymous.
Because XPath is not quite the same as XQuery makes me have to
think harder. And the fact that XPath is more restrictive, that
helps me keep track of the boundary. Anything that makes it look
more like XQuery makes me worry that I'll have a harder time
maintaining the distinction.
+ ... As to the concern, why would anyone want to do this, I use
repeated "for" instead of "," as a rhetorical device. It lets
me make it clear to six-months-from-now-me, that these are the
variables I'm going to be changing and not these other
variables. Using "for" to signal a fresh start is useful to
me.
* JL: Something that's bugging me: the "," embedded after the let
stands for "return let". When "let" is embedded, it also means
"return let". But you could write "return let", so you've got a
weirdly redundant token!
* MK: It's just saying you can leave out the return.
* RD: This is saying that these are defined in terms of single lets
and single fors because XPath originally only had one. So you had
to define the comma version as an expansion. Or was it something
like that?
* MK: It allowed the "," from the beginning. The reason that it was a
macro was to avoid adding tuple streams of bindings to the
semantics.
* DN: I hear what MSM is saying, that he doesn't want XQuery to be
mechanically put into XPath. I wouldn't object to having in XPath
an XQuery feature that gives us new functionality, but this doesn't
provide any new functionality.
* MK: From my perspective, I find laying things out with ","s much
more difficult. I've tended to standardize on putting the comma at
the beginning of the line which is ugly. Putting it at the end
makes it seems like part of the expression. The comma can disappear
at the end of the line, but the "let" stands out more.
* DN: Then we should make sure that the spec says this is for
readability or the other reasons so that it's cleary.
* JL: The note at the end of 4.13 is an example of code that's easier
to read with multple "let"s.
* DN: I wouldn't find it any harder to read if the second and
following "let"s were replaced with commas.
* RD: We don't have similar justification for any of the other parts
of the spec.
* MK: There are lots of places where we do and lots of places where
we don't.
* EP: Wouldn't it be just as good to put that in the changes
appendix?
* MSM: I think the list of changes is the right place to say that
this change is syntactic sugar. I sometimes react allergically when
changes are described as for usability when I find them less
usable.

ACTION QT4CG-022-03: MK to add a note about why multiple for and let
clauses were added to XPath

Proposal: Accept this PR

Accepted.

(MK will provide the note and then we'll merge the PR.)

2.3. PR #320: Issue 98 - add options parameter to fn:deep-equal

See [19]pull request #320. When [20]last we met, Mike was working on
test cases and an implementation. More detail is expected.
* MK: I have committed further changes. Let's take a look.
* MK: Where are we...
* MK: The collation parameter should allow empty sequence.

ACTION QT4CG-022-04: MK to update the collation parameter on
fn:deep-equal to accept an empty sequence.
* MK: I've renamed and clarified a few options.
+ ... Added `base-uri' to compare base URIs.
+ ... There was a comment about consistency of `idref' vs.
`idrefs'
+ ... I renamed one of the parameters to `normalized-space' for
consistency.

ACTION QT4CG-022-05: MK to make sure that the option list in
fn:deep-equal is sorted lexicographically
* MK: XSLT users are familiar with `preserve-space' so I went with
that name.
+ ... I expanded how equal-strings is described to include a
code implementation.
+ ... The rest is fairly mechanical...
+ ... Added a note describing how the different whitespace
handling options relate to each other.
+ ... I decided not to consider xml:space attributes.
* MSM: If you say xml:space=preserve and two documents have different
indentation, I will be preserved if they compare the same.
* MK: Basically, whitespace is significant unless you say it isn't
and there are a variety of ways to do that.
+ ... There's a note about what it means if you specify both
preserve-space and normalize-space. Basically 1 space equals 2
spaces, but no zero spaces.
* MK: The only real error condition is trying to compare functions.
You can get errors if you specify invalid options. I decided that
`false-on-error' doesn't stop invalid options from being an error.
* MK: And I added more examples. And there are many more in the test
suite.
* DN: I think this is very well done, but I would be more happy if
the default for the option `false-if-error' was true. We need a
comparison function in many other places where we don't want
errors. If we can't change it here, I want another function with
exactly the same semantics but with false-if-error set to true.
* MK: But that means that some sequences aren't equal to themselves,
which bugs me.
* DN: I think those only apply to special cases that don't arise very
often.
* RD: You can't really disregard things like NaN and infinities when
comparing values because in the IEEE specification, there's more
than one NaN. That's one of the reasons why comparing two NaN
values returns false.
* MK: In deep-equal it returns true.
* DN: We should fix that too.
* MK: We'd need a new option if we wanted to change that.
* RD: When comparing things like NaNs and infinities, what you
typically do is rely on the IEEE spec and things like the C
comparison functions that have specific behavior. We may not like
that behavior, but it is what it is.
* DN: I'm proposing a new function deep-comparison that doesn't have
backwards compatibility issues and can have any semantics we want.

We've run out of time. We'll come back to this issue in two weeks; next
week is an XSLT-focused meeting.

3. Any other business

References

1. https://qt4cg.org/meeting/minutes/2023/02-14.html#minutes
2. https://qt4cg.org/meeting/minutes/2023/02-14.html#new-actions
3. https://qt4cg.org/meeting/minutes/2023/02-14.html#administrivia
4. https://qt4cg.org/meeting/minutes/2023/02-14.html#roll-call
5. https://qt4cg.org/meeting/minutes/2023/02-14.html#agenda
6. https://qt4cg.org/meeting/minutes/2023/02-14.html#approve-minutes
7. https://qt4cg.org/meeting/minutes/2023/02-14.html#next-meeting
8. https://qt4cg.org/meeting/minutes/2023/02-14.html#open-actions
9. https://qt4cg.org/meeting/minutes/2023/02-14.html#technical-agenda
10. https://qt4cg.org/meeting/minutes/2023/02-14.html#pr-342
11. https://qt4cg.org/meeting/minutes/2023/02-14.html#pr-344
12. https://qt4cg.org/meeting/minutes/2023/02-14.html#h-8455483D-D0AF-499A-A74A-552B33A9F395
13. https://qt4cg.org/meeting/minutes/2023/02-14.html#any-other-business
14. https://qt4cg.org/meeting/agenda/2023/02-14.html
15. https://qt4cg.org/meeting/minutes/2023/02-07.html
16. https://qt4cg.org/meeting/agenda/2023/02-21.html
17. https://qt4cg.org/dashboard/#pr-342
18. https://qt4cg.org/dashboard/#pr-344
19. https://qt4cg.org/dashboard/#pr-320
20. https://qt4cg.org/meeting/minutes/2023/02-07.html#h-8455483D-D0AF-499A-A74A-552B33A9F395

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 14 February 2023 17:23:03 UTC