Re: decoupling XSLT streaming recommendations from the main spec

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

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

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