RE: Static streamability, regarding bug 29984

> >
> > It's very analogous to our rules on limits. We require processors to handle
> decimals with 16 digits, but we don't require them to report when a
> stylesheet is using decimals with more than 16 digits, and is thus straying
> outside the realm of guaranteed interoperability.
> >
> 
> I agree that the situations are analogous.   The difference seems to
> me to be that it’s not hard for me as a user to count the number of
> digits required for a value and see whether it’s greater than or less
> than sixteen, without assistance from software.  I do not believe
> the definition of guaranteed-streamable constructs is simple enough
> to apply reliably by hand.
> 

That is a valid point. But the inverse is also true: there are situations that are simple enough to see that they *ought to be* guaranteed streamable, but aren't by our rules. That is not simple to see either, nor simple to assess for software.

Another analogy is perhaps type inference:

function() { xs:integer(2) }

I believe that the signature of this function is () -> item()*. However, a processor is allowed to restrict it to an xs:integer (singular cardinality) return type.

But other processors may only infer item()*. This means a difference in static analysis between two processors: one will accept either the return type or the function as a whole in places where the other processor does not accept it.

With GS we strive to get something similar: there's a large set that all processors must adhere to, but there's some wiggle room for certain optimizations. However, these optimizations themselves are limited to the rules in the specification (i.e., there must be a valid rewrite of the expression into a GS one).  For type inference this is the same: you may be stricter, but only within the bounds of the specification.

This has shown to give users a perfectly valid set to work with. If they do receive a static error in one processor (type error), then they can fix it, even though in another processor they don't receive such error. That may happen here as well. 

Furthermore, I like the idea that the specification would be written in such a way that it does NOT limit performance improvements, and I believe expression rewriting is a performance improvement that we should not discourage.

Cheers,
Abel

Received on Thursday, 8 December 2016 15:43:38 UTC