Re: Comments on the File Module

On 6 December 2013 19:12, Tim Mills wrote:

  Hi Tim,

> Thank you for your work on this specification.

  Thank you for your interest and comments.

> The introduction of non-deterministic functions is a worry (although
> inevitable given the purpose of the specification).  Is your
> statement

> "Some function are marked as ·nondeterministic·, which means they
> are not guaranteed to perform the same operations and produce
> identical results from repeated calls. A query processor must ensure
> that these functions are not relocated or pre-evaluated and that its
> results are not cached when compiling and evaluating the query and
> serializing its results."

> enough?  If I understand XQuery correctly, the specification doesn't
> mandate an order of evaluation.  For interoperability with
> non-deterministic functions, isn't such an ordering required?

  Christian and Matthias, correct me if I am wrong, but I think the
idea here is not to define an order of evaluation, but to ensure that
the expression is no "optimized away".  Of course, this is kind of
complex to define in XPath (or XQuery or XSLT).  But for the order of
evaluation, I think the idea is more to introduce a functional
dependency where you need one.

  It would be interesting to see if it is possible to create a
functional dependency everywhere we need one, given that some
functions return nothing and/or take no parameter.  Especially since
when we decided to not have a "file handler" (a kind of black box item
that would be returned by file:open, and passed to most functions in
the same module, so to create a functional dependency between all
calls involving the same file).

> I'm also concerned by the use of functions which return a signature
> of empty-sequence(). since XQuery/XPath permits an implementation to
> raise error XPST0005 in such cases.

  Interesting.  Actually, the XPath spec defines this error in order
to catch potential typos in schema-enabled processing, making the
assumption that an expression that we know till return nothing will
be, in all possible cases, an error (the corollary of which being that
an expression cannot be called only for its side effect).  The absence
of an "empty sequence" SequenceType, in XPath 2.0, was consistent with
that approach.

  But it does not look anymore consistent to me with having the new
SequenceType "empty-sequence()" in XPath 3.0.  Especially with the
ability of declaring a function (in XQuery and XSLT)the return type of
which being "empty-sequence()".

  Should not that be considered a bug in XPath 3.0?

  Regards,

-- 
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/

Received on Monday, 9 December 2013 15:07:07 UTC