Re: decoupling XSLT streaming recommendations from the main spec

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
>>
>>
>>
>>
>
>