Re: decoupling XSLT streaming recommendations from the main spec

>
> One way for the F&O document is to try to have whenever possible just one
> overload per function and use arguments with default values wherever
> possible, which is now possible for variadic functions in XPath 4.0.
>

> I agree that we should do this. However, it should only be done once that
functionality has been ratified and we have a way of defining the default
values. This is because:
> 1. Handling default values for some functions -- such as fn:string, et.
al. that take the context item (effectively `$value := .`) -- is not
straightforward and would need consideration.
> 2. The spec does not currently define a way to specify defaults. In the
case where the end types are T*, it is not currently defined (as far as I
understand) that those reduce the lower bound of the function arity -- only
sequence types in the last position > are optional, not arbitrary functions.
>
> I have a series of issues around this (default/optional values) that we
will get to when we start discussing variadic functions and optional
parameters. At that point we would have the choice of either including some
form of that in the language, or
>  adopting it as a spec language/convention like was discussed around the
union() and enum() functionality in the case where that isn't agreed on as
a language feature.

Completely agree. As per our principle, we should handle this fundamental
issue first, and only then continue with everything that depends on it
(like presenting, wherever possible, any variadic function with just one
overload and defaults).

>
> Also, instead of two code implementations (one for XQuery and one for
> XSLT), providing just one in XPath, that is usable both for XQuery and XSLT
> may further decrease the volume twice (for the code implementations).
>
> Having two different implementations (XQuery and XSLT) also poses a tricky
> problem: How do we know that the two implementations are equivalent?
> Without a proof of this, the answer is: No we don't know with 100%
> certainty. But then, there could be differences   (even if minor/subtle)
> between different implementations :(  This is definitely avoided if we
> provide just one, XPath implementation.
>

> I would be happy with XPath provided that the use of that did not
complicate the implementation (e.g. assigning a variable to an inline
function instead of declaring the function in XQuery/XSLT).

I strongly believe that the provided **sample** implementation should not
be meant to be copied blindly. It is meant to be just one way of specifying
a precise semantics and is also a convenient oracle for testing. Beyond
that, any other implementation can be produced, provided its results are
identical with those of the oracle.

> Kind regards,
> Reece


Thanks,
Dimitre

On Fri, Sep 23, 2022 at 2:07 PM Reece Dunn <msclrhd@googlemail.com> wrote:

> On Fri, 23 Sept 2022 at 20:38, Dimitre Novatchev <dnovatchev@gmail.com>
> wrote:
>
>> >  How long do you imagine it takes even just to proof-read a 1000-page
>> document?
>>
>> If the whole document is divided between 10 people, it should be possible
>> to proofread in 2-3 weeks. Even less for an 800-page document (just the
>> "core" specification)
>>
>
> I don't think document size is a suitable metric to use (for example, the
> WHATWG version of the HTML spec is 750-800 pages, and the Java language
> spec is of a comparable size).
>
> This *could* be a useful thing to do. Given the scope of work we already
> have there are limited resources to work on doing such a split. If one or
> more people want to take up the task of doing this I wouldn't oppose that,
> but keep in mind the other work that will occupy the CG time to review and
> get right.
>
> Keep in mind that the CSS WG have been working through splitting up CSS
> 2.1 into modules and have not fully completed that work as there are still
> parts of the CSS 2.1 spec that are not in separate modules.
>
>
>> Just saying "it is not possible" doesn't seem to be constructive. Let's
>> just think what can be done to reduce the volume and complexity of the
>> specifications:
>>
>> One way for the F&O document is to try to have whenever possible just one
>> overload per function and use arguments with default values wherever
>> possible, which is now possible for variadic functions in XPath 4.0.
>>
>
> I agree that we should do this. However, it should only be done once that
> functionality has been ratified and we have a way of defining the default
> values. This is because:
> 1. Handling default values for some functions -- such as fn:string, et.
> al. that take the context item (effectively `$value := .`) -- is not
> straightforward and would need consideration.
> 2. The spec does not currently define a way to specify defaults. In the
> case where the end types are T*, it is not currently defined (as far as I
> understand) that those reduce the lower bound of the function arity -- only
> sequence types in the last position are optional, not arbitrary functions.
>
> I have a series of issues around this (default/optional values) that we
> will get to when we start discussing variadic functions and optional
> parameters. At that point we would have the choice of either including some
> form of that in the language, or adopting it as a spec language/convention
> like was discussed around the union() and enum() functionality in the case
> where that isn't agreed on as a language feature.
>
>>
>> Also, instead of two code implementations (one for XQuery and one for
>> XSLT), providing just one in XPath, that is usable both for XQuery and XSLT
>> may further decrease the volume twice (for the code implementations).
>>
>> Having two different implementations (XQuery and XSLT) also poses a
>> tricky problem: How do we know that the two implementations are equivalent?
>> Without a proof of this, the answer is: No we don't know with 100%
>> certainty. But then, there could be differences   (even if minor/subtle)
>> between different implementations :(  This is definitely avoided if we
>> provide just one, XPath implementation.
>>
>
> I would be happy with XPath provided that the use of that did not
> complicate the implementation (e.g. assigning a variable to an inline
> function instead of declaring the function in XQuery/XSLT).
>
> Kind regards,
> Reece
>
>
>> Thanks,
>> Dimitre
>>
>>
>> On Fri, Sep 23, 2022 at 12:13 PM Michael Kay <mike@saxonica.com> wrote:
>>
>>> >
>>> > But I'm suggesting to, have XSLT 4.0 come in two parts, say an XSLT
>>> 4.0 core (that can describe only XSLT's functional capabilities that
>>> doesn't include streaming/performance related recommendations), and XSLT
>>> 4.0 streaming. I agree that, this refactoring of XSLT spec is not easy to
>>> do. But the XSLT 4.0 work can spend longer time to achieve that. Till the
>>> time, such an XSLT 4.0 spec comes to light, we'll have more time to absorb
>>> the current XSLT 3.0 language.
>>> >
>>>
>>> How long do you imagine it takes even just to proof-read a 1000-page
>>> document?
>>>
>>> Michael Kay
>>>
>>>
>>>
>>>
>>
>>
>