Re: Minutes of XML Query/XSL WG Joint Teleconference #640 (2016-04-19)

On 16-04-20 06:23 AM, O'Neil Delpratt wrote:
> Minutes from XML Query/XSL WG Joint Teleconference #640, 2016-04-19
>
> DECISION: J4.4.4. The WG agreed that the example expression in March email
> message #37 are valid. Although the spec will remain unchanged.

The "Although" here is misleading, as it suggests that the spec remaining 
unchanged is not what you'd expect based on the first sentence.


> ACTION A-640-02: Mdyck to implemented proposal in the appendix A of the
> XPath and XQuery specs as described in 2b. Also to make change in the applet
> and ensure tests cases are updated in the test suite.
> Primary one is map-constructor. See:
> https://lists.w3.org/Archives/Public/public-xsl-query/2016Mar/0035.html

I'm going to treat this as three separate action items:
(a) Update the specs.
(b) Update the applets.
(c) Update the test suite.


>> J4.4.1 Bug 29501 - [xp31] Colon is not in the list of non-terminal symbols
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29501
>
> See email message:
> https://lists.w3.org/Archives/Public/public-xsl-query/2016Mar/0035.html
> ...
>
> DECISION: Bug 29501. Voted in favour of option 2b from email message
> https://lists.w3.org/Archives/Public/public-xsl-query/2016Mar/0035.html
>
> mdyck: People would be more inclined to write a colon after the NCName

No, what I said was: "In English at least, it's more common to put a space 
after a colon than before, so I think people would be more inclined to write 
columns 2 and 4, which argues for 2b over 2a."

Also, I presumably said that *before* we decided on 2b.



>> J4.4.2 Bug 29277 - [XP31] Evaluating function calls does not mention
>> evaluation of dynamic or static function calls that have no FunctionBody
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29277
>
> [...]
> I don't want have to explain the diffence between { avg($a) } and avg($a)
> Prefers the later thinks that this is the content expression

s/later/latter./

> Thinks this is editorial
>
> Mdyck: The data model uses the word expression.

This gives the wrong impression, because I then continued with something 
like "but the data model doesn't have authority over host language expressions".

> Robie: Changing our data model is a big deal at this stage.
> Mdyck: Not feeling particularly constrained to the wording used in the data
> model. It is just being too specific than it has to be.
> Mdyck: I think i said something like: The distinction between a FunctionBody
> and an expression within a FunctionBody is worth recognising.

The phrase "I think i said something like:" is what I said *afterward* about 
what I had said during the meeting. Having it appear in the minutes doesn't 
make sense.

> Mdyck: Agrees that it is editorial, but thinks that a change may be needed
> to the data model. Another way to resolve it is to leave the data model
> alone as Jonathan would refer

s/refer/prefer/


> Other point:
> Mdyck: Not clear on partial function application to a map or an array. Is
> that function a map or an array? You will get a type error

That is, a lookup operation applied to the result *would* give you a type 
error *if* we decide that it isn't a map or array. I wasn't advocating (or 
dis-advocating) that option.

> Robie Agrees with Mdyck.
>
> Mdyck: Partial function has to supply a question mark as an argument.

s/Partial function/Partial function application/

> Abel: Alternatively, a more orthogonal solution may be to let the lookup
> operators allow to operate on function items as context item, but this would
> require to remove the "If the context item is not a map or an array, a type
> error is raised" from 3.11.3.1, and possibly modifying the rules here.
>
> [...]
>
> MikeK: An array must have some run-time property which says it is an error.

s/error/array/

> The question is should partial function app have some run-time property.

I suspect:
     s/should/should the result of/
     s/app/application/
     s/some/that/

> Thinks that it should not.
>
> MikeK: Proposal is that when $F is an array or map, $F(?) is legal, and the
> result is a function that is not a map nor an array.
>
> Robie: Thinks we would have to add some new information to section 2.8.1
> Functions DM31.

No, Jonathan was saying we would need to add something to XQuery/XPath 
"Evaluating Function Calls" section, not to the Data Model.

> Abel: @MKay: so, if $F is a map, then $F instance of map(*) succeeds, $F(?)
> instance of map(*) fails? But is it still cartable?

s/cartable/castable/

This leaves out MKay's response: "there's no such thing as casting to a map 
or array".



> Abel added notes in https://www.w3.org/Bugs/Public/show_bug.cgi?id=29277#c20
> discussed each point.
>
> jrobie: If F's implementation is not an XQuery 3.1 expression (e.g., F is a
> built-in function or an external function or a partial application of such a
> function)

That's a quote from the spec. It's unclear how it relates to any of Abel's 
points.

> robie suggests :  An API used to invoke external functions must state how
> the static and dynamic contexts are provided to a function that is invoked.

That isn't a suggestion, that's just a quote from the spec.



>> J4.4.4 Necessary whitespace?
>> See: https://lists.w3.org/Archives/Public/public-xsl-query/2016Mar/0037.html
>
> [...]
> Examples match the grammar given that you are generating the grammar.

I wasn't talking about generating the grammar, but generating sentences 
conforming to the grammar. I said something like: The examples match the 
grammar in that they are sentences that can be derived from the start symbol 
according to the grammar.

> MikeK: There are two exceptions to this, that of "." and "-", which do
> require a symbol separator if they follow a QName or NCName.

That's a quote from the spec, and wasn't a response to what I said.

-Michael

Received on Monday, 25 April 2016 20:44:19 UTC