Re: QT4 CG meeting 0012 draft minutes 2022-11-22

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