- From: Dimitre Novatchev <dnovatchev@gmail.com>
- Date: Tue, 22 Nov 2022 10:01:00 -0800
- To: Norm Tovey-Walsh <norm@saxonica.com>
- Cc: public-xslt-40@w3.org
- Message-ID: <CAK4KnZfJJ8V3VUmH0+E2djFgYo0F3cj4cGUsDdKetCcwE34dOw@mail.gmail.com>
Hi Norm, Thanks for taking the minutes so promptly and accurately. Just two minor things: > * DN: Maybe it would be good to list explicitly all the atomic types. I meant "all primitive atomic types" > We could also consider root / stock. I meant "stalk", like "stem" Thanks, Dimitre On Tue, Nov 22, 2022 at 9:35 AM Norm Tovey-Walsh <norm@saxonica.com> wrote: > See > > https://qt4cg.org/meeting/minutes/2022/11-22.html > > QT4 CG Meeting 012 Minutes 2022-11-22 > > Table of Contents > > * [1]Draft Minutes > * [2]Summary of new and continuing actions [0/9] > * [3]1. Administrivia > + [4]1.1. Roll call [8/13] > + [5]1.2. Accept the agenda > + [6]1.3. Next meeting > + [7]1.4. Approve minutes of the previous meeting > + [8]1.5. Review of open action items [7/8] > * [9]2. Technical Agenda > + [10]2.1. Review pull request #232: Data model clarifications, > issue #225 > + [11]2.2. Review pull request #237: XSL conditionals > + [12]2.3. Review pull request #247 > + [13]2.4. Review pull request #249: fn:items-at, issue #213 > + [14]2.5. Review pull request #250: fn:foot, etc. > * [15]3. Any other business > > Draft Minutes > > Summary of new and continuing actions [0/9] > > * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving > diversity in the group > * [ ] QT4CG-012-01: MK to add a reference to the place in XSD where > it says that value spaces are non-overlapping > * [ ] QT4CG-012-02: MK to point out the rules for union types are > actually a bit more complex than described in section 2.2.1. > * [ ] QT4CG-012-03: MK to consider introducing schema element and > schema element in 2.8 > * [ ] QT4CG-012-04: MK to add "and also of other specific function > types" to 2.8. > * [ ] QT4CG-012-05: NW to see if the presentation of the type > hierarchy tables can be improved. > * [ ] QT4CG-012-06: MK to remove xs:untyped from the paragraph at the > top of 2.8.2 > * [ ] QT4CG-012-07: NW to work with MK to sort out the server build > issues with PR #237 > * [ ] QT4CG-012-08: NW to put the coercion rule changes on the agenda > next week. > > 1. Administrivia > > 1.1. Roll call [8/13] > > Regrets BTW, JL > * [ ] Anthony (Tony) Bufort (AB) > * [X] Reece Dunn (RD) > * [X] Christian Gr¸n (CG) > * [X] Joel Kalvesmaki (JK) [0:20-] > * [X] Michael Kay (MK) > * [ ] John Lumley (JL) > * [X] Dimitre Novatchev (DN) > * [X] Ed Porter (EP) > * [ ] Liam Quin (LQ) > * [ ] Adam Retter > * [X] C. M. Sperberg-McQueen (MSM) > * [ ] Bethan Tovey-Walsh (BTW) > * [X] Norm Tovey-Walsh (NW). Scribe. Chair. > > 1.2. Accept the agenda > > Proposal: Accept [16]the agenda. > > Accepted. > > 1.3. Next meeting > > The next meeting [17]is scheduled for Tuesday, 29 November. > > Regrets: JL > > 1.4. Approve minutes of the previous meeting > > Proposal: Accept [18]the minutes of the previous meeting. > > Accepted. > > 1.5. Review of open action items [7/8] > > * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving > diversity in the group > * [X] QT4CG-011-01: MK to fix the reference to "function" in XPath > 4.4.1. > + [19]pull request #247 > * [X] QT4CG-011-02: CG to work with DN to propose an "until" variant. > + Withdrawn, > [20]https://lists.w3.org/Archives/Public/public-xslt-40/2022No > v/0022.html > * [X] QT4CG-011-03: MK to change the references to URI qualified name > in both QName-related functions. > + [21]pull request #247 > * [X] QT4CG-011-04: NW to define the parse-uri/build-uri record types > in a separate section > + [22]https://lists.w3.org/Archives/Public/public-xslt-40/2022No > v/0021.html > * [X] QT4CG-011-05: NW to update the history for parse-uri/build-uri > to indicate that details are still being resolved > + [23]https://lists.w3.org/Archives/Public/public-xslt-40/2022No > v/0021.html > * [X] QT4CG-011-06: NW to make sure ednotes are rendered. > + [24]https://lists.w3.org/Archives/Public/public-xslt-40/2022No > v/0021.html > * [X] QT4CG-011-07: NW to make sure the meeting passcode is on the > logistics page > + This is already the case > > 2. Technical Agenda > > 2.1. Review pull request #232: Data model clarifications, issue #225 > > See [25]pull request #232 > * MK: Mostly in response to MSM's comment about better description of > data values and type annotations > + ... Cleaned up the Introduction; added missing definitions > + ... Added 2.2 Basic Concepts > + ... Tried to make minimal changes > + ... We do use the terms value and sequence synonymously, > nothing we can do about that. > + ... "Instance of the data model" is a synonym for sequence > + ... Define "item type" > + ... Cleaned up the term "tree" > + ... Changed definition of atomic value to say it's a pair of a > type annotation and a datum. > + ... Clarified that datums cannot have overlapping value spaces > > ACTION QT4CG-012-01: MK to add a reference to the place in XSD where it > says that value spaces are non-overlapping > * MSM: I thought value spaces did overlap > * MK: If you use identity, the value spaces don't overlap. > * MSM: I would have thought it was simpler to say that a given datum > may appear in more than one value space, but as an atomic value, > they are different. > * DN: Maybe it would be good to list explicitly all the atomic types. > > General agreement that the atomic types are listed in the spec later > on. > * MK continues > + ... Note that type annotation means slightly different things > for nodes and atomic values. > + ... Defined "schema type" > + ... Attempt to clarify the relationship between schema types > and item types > * RD: Suggests changing the prose to make it clear that "pure union > types" are only of atomic types. > * MK: We need to come back to that, I'm avoiding it here for the > moment. > > ACTION QT4CG-012-02: MK to point out the rules for union types are > actually a bit more complex than described in section 2.2.1. > * MK continues > + ... Getting away from the idea that every item has a most > specific item type. > + ... Every item is an instance of one or more item types > + ... Atomic values do have a most specific item type > * RD: Because you're using item type syntax, "document()" needs to be > "document-node()" etc. > * MK: Right. > > Some discussion of wether or not all attributes are instances of > attribute(*). > > ACTION QT4CG-012-03: MK to consider introducing schema element and > schema element in 2.8 > * MSM: Is there just one function type? > * MK: No, it will also be an instance of a more general function type > based on co-variance and contra-variance. > * MSM: Then adding that there are also other types, parallel to the > wording for maps. > > ACTION QT4CG-012-04: MK to add "and also of other specific function > types" to 2.8. > * MK: The data model tended to assume that all types are named; I've > added a few notes about anonymous types. > * DN: Maybe say they don't have "permanent names" > * MK: If they do have names, the names aren't exposed. > * DN: We don't have a "type object" in the data model; I think we > should add one. > * RD: In the formal semantics for XPath and XQuery 1.0, there was an > XPath- and XQuery-like formulation of the XML schema data model. > * MK: I haven't looked at that spec for a very long time; I'll take > another look. > * MSM: I have one concern which is that I seem to remember that in > the early days of the QT work, the formalists said that it > complicates things too much if we say that types sometimes have a > name and sometimes don't, so we're just going to assume they always > do. So my concern about this note is that we don't want to > introduce a pervasive problem. > * MK: That's scattered about a bit, but no where do we explicitly say > that. > * MSM: As we work through the specs, everyone please keep an eye open > for ramifications. > > ACTION QT4CG-012-05: NW to see if the presentation of the type > hierarchy tables can be improved. > * RD: Should we be specifying the value space of the untyped- and > any-typed types? > * MK: Yes, probably. I haven't made any changes in that area. > + ... There's an error here, xs:untyped is not an atomic type. > > ACTION QT4CG-012-06: MK to remove xs:untyped from the paragraph at the > top of 2.8.2 > * MSM: To address RD's concern, I don't know what the value space of > untypedAtomic is. The value space that seems obvious to me is that > untypedAtomic has the union of the value spaces of all the > primitive types. That was explicitly suggested by the schema > working group, but the QT group said "nah". > * RD: Wouldn't untypedAtomic be better being the same value space as > xs:string? > * MSM: That's ok for the lexical space, but for the value space, > shouldn't the assignment of a more specific type be a refinement? > Typing an xs:string as an xs:integer is not a refinement. > * RD: But the infoset-mapping section says that an attribute or text > value has a "data" type that's of xs:untypedAtomic. It doesn't make > sense there to say the union of all possible types. > * MK: We always describe moving from an untypedAtomic to something > else as "casting". > * RD: Also, the casting rules treat xs:string and xs:untypedAtomic > identically. > * MK: They're identical for nearly all purposes except for the > behavior of the coercion rules. > > Proposal: accept this PR. > > Accepted. > > 2.2. Review pull request #237: XSL conditionals > > See [26]pull request #237 > * MK: I did a revised PR that was responsive to the actions I was > given, but also went a little further. It builds locally but not on > the server. > > ACTION QT4CG-012-07: NW to work with MK to sort out the server build > issues with PR #237 > > 2.3. Review pull request #247 > > See [27]pull request #247 which resolves MK actions QT4CG-011-01 and > QT4CG-011-03 > * MK: The first is completely trivial, just a one word change. > > On review, these are just markup fixes. > > Proposal: Accept this PR. > > Accepted. > > 2.4. Review pull request #249: fn:items-at, issue #213 > > See [28]pull request #249 > * MK reviews fn:items-at() > + ... One doubt I had is that the most common use is going to be > a single number, so it's not clear if item-at would be better. > But I used the plural. > + ... The use cases for this are primarily where the square > bracket predicate notation gives you problems with the context > item. > + ... The use cases for returning multiple items are sometimes > equivalent to subsequence > + ... One point of detail is should this be like substring and > subsequence and take xs:double instead of integers. > + ... We had a big debate about this with respect to functions > we added before. I think we got that right, the explicit cast > is useful and the cases where it's needed are quite rare. > + ... If you use xs:double you have to talk about what happens > if it's not an exact whole number. > * CG: How about xs:nonNegativeInteger? > * MK: Yes, once we get the coercion rules sorted out. > * MSM: I can still cast to xs:integer, yes? > * MK: Yes, if we accept the change to the coercion rules. > * DN: I think it might be useful to allow negative integers, which > take from the end, like Python > * DN: We should add a corresponding array function, fn:members-at()? > * MK: If we do add negative numbers, we should add it everywhere that > it's appropriate, for example fn:remove(). > > ACTION QT4CG-012-08: NW to put the coercion rule changes on the agenda > next week. > > NW asks if there's any possibility of harmonizing arrays and sequences > for functions? > * MK: I've proposed a way to parcel and unparcel arrays and sequences > so that it's easier. But it's hard to make that nice and usable > without explicit parceling. > * RD: If we had explicit union types, we could... > * MK: No, we couldn't, we have this wretched problem that an array is > a sequence of length one. > > Returning to items-at... > * CD: I think doubles would be better than integers because that > would make it easier to rewrite predicates to this function. But > you could say that was an optimization issue not something a user > has to be concerned about? > > The CG is not moved to make that change. > > Proposal: Accept this PR > > Accepted. > > 2.5. Review pull request #250: fn:foot, etc. > > See [29]pull request #250 > * DN: I find the names not good, especially truncate. Where head / > tail make a pair, foot / truncate don't. I proposed heel. We could > also consider root / stock. The other thing that's more serious is > that the corresponding functions for arrays will raise exceptions > when the first argument is the empty sequence, but here we're > returning the empty sequence. The semantics are not similar. I > think an additional argument that has a default to raise an > exception. > * MK: The issue of array bounds checking is a very good issue and a > very difficult one. I think it's indefensible that we have array > bounds checking on arrays and not sequences. It's a classic working > group kind of artifact that introduces an enormous > non-orthogonality in the language. At the same time, that's a > problem that's enormously difficult to fix. I tend to want to keep > things consistent whenever possible. > > Out of time. > > 3. Any other business > > * RD: Can folks look over my parse-html PR? > * MK: That's good work, and needs careful review. > * CG: I proposed in email that we could reference issues from the QT > specs with the hash symbol and a number. Then we'd get linking from > PRs to issues and commits. > * NW: Good idea. > > References > > 1. https://qt4cg.org/meeting/minutes/2022/11-22.html#minutes > 2. https://qt4cg.org/meeting/minutes/2022/11-22.html#new-actions > 3. https://qt4cg.org/meeting/minutes/2022/11-22.html#administrivia > 4. https://qt4cg.org/meeting/minutes/2022/11-22.html#roll-call > 5. https://qt4cg.org/meeting/minutes/2022/11-22.html#agenda > 6. https://qt4cg.org/meeting/minutes/2022/11-22.html#next-meeting > 7. https://qt4cg.org/meeting/minutes/2022/11-22.html#approve-minutes > 8. https://qt4cg.org/meeting/minutes/2022/11-22.html#open-actions > 9. https://qt4cg.org/meeting/minutes/2022/11-22.html#technical-agenda > 10. https://qt4cg.org/meeting/minutes/2022/11-22.html#pr-data-model > 11. https://qt4cg.org/meeting/minutes/2022/11-22.html#xsl-conditionals > 12. https://qt4cg.org/meeting/minutes/2022/11-22.html#pr-qt4cg-011-01 > 13. https://qt4cg.org/meeting/minutes/2022/11-22.html#pr-items-at > 14. https://qt4cg.org/meeting/minutes/2022/11-22.html#pr-fn-foot > 15. https://qt4cg.org/meeting/minutes/2022/11-22.html#any-other-business > 16. https://qt4cg.org/meeting/agenda/2022/11-22.html > 17. https://qt4cg.org/meeting/agenda/2022/11-29.html > 18. https://qt4cg.org/meeting/minutes/2022/11-15.html > 19. https://qt4cg.org/dashboard/#pr-247 > 20. > https://lists.w3.org/Archives/Public/public-xslt-40/2022Nov/0022.html > 21. https://qt4cg.org/dashboard/#pr-247 > 22. > https://lists.w3.org/Archives/Public/public-xslt-40/2022Nov/0021.html > 23. > https://lists.w3.org/Archives/Public/public-xslt-40/2022Nov/0021.html > 24. > https://lists.w3.org/Archives/Public/public-xslt-40/2022Nov/0021.html > 25. https://qt4cg.org/dashboard/#pr-232 > 26. https://qt4cg.org/dashboard/#pr-237 > 27. https://qt4cg.org/dashboard/#pr-247 > 28. https://qt4cg.org/dashboard/#pr-249 > 29. https://qt4cg.org/dashboard/#pr-250 > > Be seeing you, > norm > > -- > Norm Tovey-Walsh > Saxonica >
Received on Tuesday, 22 November 2022 18:01:26 UTC