RE: [F&O] Function for self-evaluation?

I expect some XQuery functions to provide an eval() function. However, I
(and others) have not considered it a feature that all implementations
can or have to provide.

As to fn:data(): the static result type of fn:data() is actually quite
precise (the static type is determined based on the static type of the
input argument).

As to the security issues: There will be XQuery implementations that
will have to worry about that (one of the reason why we should not
require the standard to require this function.

As to the inconsistency argument: I don't quite follow you why the
position on not wanting external variables somehow should be tied to
this discussion. 

Finally, I did not use the argument of it being a burden to
implementers. Although as you should know, there is more to the cost of
implementing than to code it...

Best regards
Michael

> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Michael Brundage
> Sent: Monday, October 13, 2003 8:04 PM
> To: Michael Rys; 'Sarah Wilkin'; public-qt-comments@w3.org
> Subject: RE: [F&O] Function for self-evaluation?
> 
> 
> I'm also in favor of an eval() function, and expect most of the better
> XQuery implementations to provide one.
> 
> Statically, you'd type it as item()*.  Static typing hasn't prevented
the
> introduction of the data() function, which extracts the typed value of
a
> sequence without having the most specific static type.
> 
> Also, the security issue is moot; eval() doesn't have permission to do
> anything the user couldn't already do.
> Javascript and Perl both have eval.
> 
> Code injection is only an issue if eval() takes only a string.  If it
also
> takes variable bindings (possibly the ones already in scope), then one
> could
> use parameterized queries and avoid injection.  But code injection is
> already an issue for XQuery in general, just as it is for SQL.  It's
> inconsistent that the committee long resisted external parameters --
which
> are critical in avoiding query injection -- and now uses injection as
an
> argument against eval.
> 
> And finally, I fail to see how eval() is any burden to implementers at
> all.
> In its simplest form, eval() simply recursively calls their own
> implementation to compile and execute the query string with the same
> static
> and dynamic environment as the original.  If we're talking
implementation
> burdens, let's discuss static typing, arbitrary-precision numerics,
formal
> semantics, and the PSVI data model.
> 
> Eval() is the tiniest fleck in the XQuery universe of features.  If
it's
> really such an obstacle, add it to a non-normative list of suggested
> functions (and put half of the existing F&O there with it).
> 
> 
> 
> Cheers,
> michael
> 
> -----Original Message-----
> From: public-qt-comments-request@w3.org
> [mailto:public-qt-comments-request@w3.org] On Behalf Of Michael Rys
> Sent: Monday, October 13, 2003 5:01 PM
> To: Sarah Wilkin; public-qt-comments@w3.org
> Subject: RE: [F&O] Function for self-evaluation?
> 
> 
> 
> We have looked at the function eval(). However, we felt that such a
> function adds too much dynamic behaviour, that we cannot request from
> every implementation.
> 
> It is also a function that has security issues (such as code
insertion)
> and does not work well with statically typed systems.
> 
> Best regards
> Michael
> 
> > -----Original Message-----
> > From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> > request@w3.org] On Behalf Of Sarah Wilkin
> > Sent: Monday, October 13, 2003 4:56 PM
> > To: public-qt-comments@w3.org
> > Subject: [F&O] Function for self-evaluation?
> >
> >
> > One function we added to our XQuery implementation is eval(), which
> > takes a string and evaluates it as an XQuery expression. I'm
wondering
> > if the working group has considered adding such a function.
> >
> > The most obvious use case is a query that needs to be marked up and
> > executed later. For example, in the NIST test suite, a test looks
> like:
> > 	<results>
> > 		{fn:boolean(xs:double("-1.7976931348623157E308"))}
> > 	</results>
> > So an implementor is somehow expected to read in the whole file and
> > execute it as XQuery. If eval is supported, the same file can become
> > 	<results>
> > 		fn:boolean(xs:double("-1.7976931348623157E308"))
> > 	</results>
> > And the test may be evaluated with XQuery itself:
> > 	eval(doc("test.xml")/results/string())
> >
> > There are, of course, many other uses. The is not merely a
> "convenience
> > method" as it could never be written as a user-defined function. Any
> > comments are appreciated.
> >
> > --Sarah
> >
> 
>

Received on Tuesday, 14 October 2003 00:45:00 UTC