Re: [XQueryX] 5 A Trivial Embedding of XQuery

David,

Many thanks for your comment.  This message contains my personal 
observations and do not in any way reflect a Working Group response.  The 
Query Working Group will respond formally as soon as they have developed an 
official response.

You observe correctly (in your third paragraph below) that "no indication 
is given...about which embedding has been used".  In fact, speaking as an 
Editor of the XQueryX specification, that was deliberate.  Section 5 was 
intended, not to specify a normative way to do a trivial embedding of 
XQuery in an XML document, but to demonstrate that the subject has been 
considered and to suggest some (certainly not all!) approaches that a user 
might follow if a trivial embedding is required for his or her purposes.

Of course, a conformance statement in the XQueryX document would have to 
make it clear what is normative and what is not.  I confess (speaking again 
as an Editor) that I should thought about moving Section 5 into a 
non-normative appendix.  I will discuss this possibility with my co-Editors.

The Working Group, of course, will have to make the decision about whether 
to include any trivial embedding in the normative components of XQueryX, to 
move it to a non-normative part of the document, or to delete it entirely.

You may be assured that the Working Group continues to develop the XQueryX 
specifications in active pursuit of progression.

Again, thanks for your comment.

Hope this helps,
    Jim

At 04:05 2004-01-14 Wednesday, David Carlisle wrote:



>I believe that the approach outlined in this section is very dangerous
>and can easily lead to queries being accidentally or maliciously altered.
>
>It is unfortunate that XQuery misuses XML syntax for a non XML language
>(previous comments to this list on XML Query have suggested that it does
>not do that, but I assume now that the current syntax is fixed) However
>this means that great care needs to be taken when inserting XML Query
>fragments into XML documents.
>
>Even in this small section, three different embeddings are suggested,
>and no indication is given in the embedding syntax about which embedding
>has been used.
>
>Most problematic are situations where extracting the query using the
>wrong embedding produce a valid, but different, Xquery from the one
>intended.
>
>For example the second embedding shown
>
><XQuery><![CDATA[for $i... let $j...where $x < $y...return...]]></XQuery>
>
>
>Could (if the XML parser used, reports CDATA sections) be extracted using
>the embedding used for the first example. the result would be that
>instead of getting an Xquery FOR expression, you get an Xquery CDATA
>constructor, this is a perfectly valid Xquery expression. Of course one
>might to be expected to use common sense to distinguish the cases, but
>machines are not too good at common sense, and in harder cases it would
>be harder to guess.
>
>Similar things occur with
>
><XQuery> ("abc&#34;,&#34;xyz") </XqueryX>
>
>If you put that "trivial" embedding through an XML parser which reports
>that the content of the XQuery element is
>  ("abc","xyz")
>then I don't see how you could reliably decide whether the original
>expression was a sequence of one or two strings.
>
>Other problems exist with things such as Xquery Comment constructors
>if these are embedded using the first scheme (ie just literally
>included) then whether or not the extracted query contains a comment
>constructor will depend on whether the XML parser used reports
>comments.
>
>
>My preferred solution would be to modify the Xquery syntax so that the
>first suggested embedding is always legal and safe, this means
>essentially not using unescaped <, modifying the rules for the timing of
>the expansion of character references, and using a different syntax for
>comment and pi constructors (as in xslt) however failing that: section 5
>should be dropped or replaced by a much more fully spec'd proposal that
>would allow Xqueries to be unambiguously and safely embedded in XML
>documents.
>
>David
>
>________________________________________________________________________
>This e-mail has been scanned for all viruses by Star Internet. The
>service is powered by MessageLabs. For more information on a proactive
>anti-virus service working around the clock, around the globe, visit:
>http://www.star.net.uk
>________________________________________________________________________

========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
Oracle Corporation            Oracle Email: mailto:jim.melton@oracle.com
1930 Viscounti Drive          Standards email: mailto:jim.melton@acm.org
Sandy, UT 84093-1063              Personal email: mailto:jim@melton.name
USA                                                Fax : +1.801.942.3345
========================================================================
=  Facts are facts.  However, any opinions expressed are the opinions  =
=  only of myself and may or may not reflect the opinions of anybody   =
=  else with whom I may or may not have discussed the issues at hand.  =
========================================================================

Received on Wednesday, 14 January 2004 17:58:40 UTC