- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 28 Feb 2023 17:23:08 +0000
- To: public-xslt-40@w3.org
- Message-ID: <m2pm9titzw.fsf@saxonica.com>
Hi folks,
Here are the draft minutes for meeting 024, 28 February 2023.
https://qt4cg.org/meeting/minutes/2023/02-28.html
QT4 CG Meeting 024 Minutes 2023-02-28
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/10]
* [3]1. Administrivia
+ [4]1.1. Roll call [10/12]
+ [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 [6/10]
* [9]2. Technical Agenda
+ [10]2.1. Issues recommended for closure
+ [11]2.2. PR #320: Issue 98 - add options parameter to
fn:deep-equal
* [12]3. Any other business
Draft Minutes
Summary of new and continuing actions [0/10]
* [ ] 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-023-01: NW to review the stylesheets for functions across
XPath and XSLT
* [ ] QT4CG-023-05: NW to put record types on an agenda.
* [ ] QT4CG-024-01: MK to add namespace-uri-for-prefix argument
changes to the compatibility appendix
* [ ] QT4CG-024-02: DN to develop an alternative proposal for
deep-action.
* [ ] QT4CG-024-03: NW to create issues for improving fn:deep-equal
1. Administrivia
1.1. Roll call [10/12]
Regrets: BTW
* [ ] Anthony (Tony) Bufort (AB)
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK) [:10-]
* [X] Michael Kay (MK)
* [X] John Lumley (JL)
* [X] Dimitre Novatchev (DN)
* [X] Ed Porter (EP)
* [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 [13]the agenda.
Accepted.
1.3. Approve minutes of the previous meeting
Proposal: Accept [14]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting [15]is scheduled for Tuesday, 7 March 2023.
No regrets heard.
1.5. Review of open action items [6/10]
* [ ] 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.
* [X] QT4CG-021-03: RD to change must to will in DOM notes about
lowercase
* [X] QT4CG-021-04: RD to revise and move the note about unrecognized
entities
* [ ] QT4CG-023-01: NW to review the stylesheets for functions across
XPath and XSLT
* [X] QT4CG-023-02: MK to write a PR to drop xsl:function-library
from the spec.
* [X] QT4CG-023-03: MK to start a new thread for discussion function
namespace flexibility
* [X] QT4CG-023-04: MK to review and develop a proposal for
separating element and type default namespaces
* [ ] QT4CG-023-05: NW to put record types on an agenda.
* [X] QT4CG-023-06: MK to revisit and make a PR for an as attribute
on xsl:mode
2. Technical Agenda
2.1. Issues recommended for closure
An [16]email proposal from MK.
Mike walks us through the email.
* MK: Are any of these non-contentious?
+ [17]#45, you can always write your own vendor-defined version
+ [18]#60, the function assumes you can downcase strings, so
there's no issue except perhaps the previous error code
+ [19]#112, leave open for now
+ [20]#147, no concrete proposal, close
+ [21]#260, essentially indistinguishable from array:index-where
o DN: I think it's confusing to have functions with
different names in this area.
# ... I think we should also have array:deep-index-of,
I will propose that
# ... Please keep this one open.
ACTION QT4CG-024-01: MK to add namespace-uri-for-prefix argument
changes to the compatibility appendix
2.2. PR #320: Issue 98 - add options parameter to fn:deep-equal
See [22]pull request #320. We ran out of time while [23]discussing this
in meeting 22.
* CG: Let's look at the comments in the PR
* NW: Good idea.
We turn our attention to [24]PR #320 comments.
* CG: I think we should consider unordered-children as a better name.
* MK: The property is a set of element names that has the semantics
that there is no ordering among any of the children of those
elements.
* CG: My idea was we could ignore the order of nodes generally and
not consider comments or elements; I think we could avoid looking
at element names.
* MK: All children of all elements? That seems unlikely to me
* RD: I think one case where the generalization could be useful is in
unordered content of key values. Possibly. But I don't see any
other cases where that would apply.
* MSM: In general, I'm a fan of anything that's a generalization, but
I don't understand. Does anything have children other than an
element?
* CG: A comment could occur before or after an element.
* RD: Deep equal also applies to sequences of items.
* MSM: But do any of the items have anything that our specs call
"children"
* MK: Should we look at what the proposed spec actually says?
* MSM: Yes, but calling it unordered-elements does make me wonder if
users might think they should name the elements whose order doesn't
matter!
* RD: Should we have separate issues for generlizing this?
* CG: It might make sense to have a use case that clarifies the
usefulness of unordered comparisons.
MK brings up the specification prose.
* MK reads clause J.IV.
+ ... It is about the order of all of the children of selected
elements.
* MSM: Can I specify `*' as an option?
* MK: Not at the moment, but we could add that.
* JL: Is there a case for this to allowed to be wildcarded in the
namespace or the local name?
* MK: It just makes the API more complex.
General agreement that there might be use-cases for both of those
* CG: Would it be possible to write the test for permutations in
XQuery?
* MK: Yes, perhaps, but it's not easy.
MK describes the implementation he's got which uses a hashcode for each
child and then compares the hashcode in an N^2 comparison.
* RD: You could do something similar in XQuery if you had a version
of deep-equals that returned the hash
* MK: I'd like to say we're not completely happy with
unordered-elements, so take it out and reopen it as a new issue.
* MSM: I'd be happy to accept the proposal with the current treatment
for unordered elements and consider adding wildcards as a new
issue.
* JL: I'd agree with that.
* DN: It seems to me that this function is extremely complicated. I
think we should break this into simpler problems. We could have a
function deep-equal and then have different functions for each
case: documents-equal, elements-equal, atomic-values-equal, etc.
* RD: In terms of this function, the complexity in the implementation
already exists. Effetively all this proposal is doing is allowing
certain of the deep-equal features to be optional. Well, mostly. A
lot of the complexity is already there. If you have a complicated
structure where you have a map of elements or a map of arrays of
elements, you'll have to pass through the options. I don't think
you can separate out the different behaviors that this function is
doing.
* MK: DN has come up with an interesting alternative idea, can we ask
him to expand on that so we can compare them.
* DN: What is the task?
* MK: Rather than these boolean options, propose an alternative
design.
ACTION QT4CG-024-02: DN to develop an alternative proposal for
deep-action.
* DN: I have very strong objection to not making
treat-errors-as-false the default.
* MK: I'm very reluctant to have a situation where something is not
equal to itself by default.
Some discussion of the NaN problem; the assertion is that these are
exceptional cases.
* RD: Different languages can specify different comparison behaviors.
JavaScript and Java specify different behavior on things like NaN.
I think one of the difficulties with trying to fit rigerous
mathematical descriptions of numeric types is that you run into
issues like the numbers are fixed, limited value. While 300 is a
valid integer, it's not in the set of unsigned bytes. If you add
two unsigned bytes you can...
* MK: I'd like to observer that this is a change to how deep-equal
handles node trees, not numbers. Can we do that separately?
* DN: We need a comparison function in lots of places and it should
always return a value. The only thing we don't agree on is what to
do when there are two function items. We can just consider them
unequal unless there's some way to show that they're equal. I don't
like that a set of one function item would not be equal to itself.
But that's just a special case.
* NW: This is just about the default? (Yes.)
* CG: I think those (NaN, INF, etc.) are separate issues like MK and
RD said.
* JK: I support the proposal; but we only got half way down through
the issues...
* JK: The two-whitespace options appear to have overlapping domains.
* MK: Yes, I wish there was a better way.
* JK: I think you need to specify what happens in the overlapping
cases, and to make the defaults such that there isn't any overlap.
I vote for normalizing true and stripping false.
* MK: I think the rules are all there; I think I tried to clarify the
description on the basis of these comments.
* RD: In XQuery there's a boundary-space property...
* MK: The first thing to do is factor out what the options are.
Normalizing whitespace where there's a mixture of text nodes on the
one hand, stripping indentation on another.
* JK: I think there are probably three levels of stripping.
* MK: Yes, probably.
* MSM: Can someone describe the three options?
* MK: The "ruthless" option is that you remove all text nodes that
are whitespace only and you also normalize space in text nodes that
contain a mixture of whitespace and non-whitespace characters.
+ ... The next option is that you ignore "layout whitespace",
but you treat whitespace in other nodes as significant.
* MSM: Every memory I have of phrases like "layout whitespace" is
painful.
+ ... I think there are three levels in XSD but I don't think
they have the same kind of "black pit" quality.
+ ... The middle ground is that adjacent whitespace characters
are replaced with a single blank.
* RD: We've got "not preserved" and "not normalized" and "not
preserved" and "normalized" which are the same thing. ... RD
describes the other options in the state table...
+ ... So I think all the options make some kind of sense.
* MK: The note in the spec now attempts to present the synthesis of
the options.
Proposal: accept this PR, with three new issues:
1. What should the default be for the issue of errors
2. Can whitespace handling be improved?
3. Can the specification of unordered be improved?
ACTION QT4CG-024-03: NW to create issues for improving fn:deep-equal
3. Any other business
* MK: There are a lot of open PRs.
* NW: I'm happy to put small things at the top next week
* RD: Can we also go through the features added prior to the
formation of the WG? Can we get to the point where all of those are
agreed.
NW observes that if there aren't bugs for some of those, then the
easiest way forward is to create bugs. That helps organize the agendas.
* CG: Spend one minute to look at the existing PRs?
MK walks through them: 375 is a bug so that should have high priority,
368 is large, 364 is small, 363 is small, 355 is almost editorial.
NW to try to put some low hanging fruit on the agenda for next week.
NW: Suggestions for low hanging fruit and proposals to resolve issues
in email most eagerly accepted!
References
1. https://qt4cg.org/meeting/minutes/2023/02-28.html#minutes
2. https://qt4cg.org/meeting/minutes/2023/02-28.html#new-actions
3. https://qt4cg.org/meeting/minutes/2023/02-28.html#administrivia
4. https://qt4cg.org/meeting/minutes/2023/02-28.html#roll-call
5. https://qt4cg.org/meeting/minutes/2023/02-28.html#agenda
6. https://qt4cg.org/meeting/minutes/2023/02-28.html#approve-minutes
7. https://qt4cg.org/meeting/minutes/2023/02-28.html#next-meeting
8. https://qt4cg.org/meeting/minutes/2023/02-28.html#open-actions
9. https://qt4cg.org/meeting/minutes/2023/02-28.html#technical-agenda
10. https://qt4cg.org/meeting/minutes/2023/02-28.html#closure
11. https://qt4cg.org/meeting/minutes/2023/02-28.html#pr320
12. https://qt4cg.org/meeting/minutes/2023/02-28.html#any-other-business
13. https://qt4cg.org/meeting/agenda/2023/02-28.html
14. https://qt4cg.org/meeting/minutes/2023/02-21.html
15. https://qt4cg.org/meeting/agenda/2023/03-07.html
16. https://lists.w3.org/Archives/Public/public-xslt-40/2023Feb/0020.html
17. https://github.com/qt4cg/qtspecs/issues/45
18. https://github.com/qt4cg/qtspecs/issues/60
19. https://github.com/qt4cg/qtspecs/issues/112
20. https://github.com/qt4cg/qtspecs/issues/147
21. https://github.com/qt4cg/qtspecs/issues/260
22. https://qt4cg.org/dashboard/#pr-320
23. https://qt4cg.org/meeting/minutes/2023/02-14.html#h-8455483D-D0AF-499A-A74A-552B33A9F395
24. https://github.com/qt4cg/qtspecs/pull/320
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 28 February 2023 17:24:06 UTC