W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2003

RE: Whitespace in XQuery 1.0

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Tue, 2 Sep 2003 22:51:11 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106073DD0CF@daemsg02.software-ag.de>
To: Kevin Jones <kjones@actuate.com>, public-qt-comments@w3.org
Spaces are required between adjacent keywords such as "treat as". This is
implicit in the "longest token" rule: if there were no space, there would be
a single token "treatas", which would not be recognized by the grammar.
 
Perhaps this needs further clarification.
 
Michael Kay
 
 
-----Original Message-----
From: Kevin Jones [mailto:kjones@actuate.com] 
Sent: 02 September 2003 20:50
To: public-qt-comments@w3.org
Subject: Whitespace in XQuery 1.0



We are trying to validate our understanding of the XQuery lexical
productions.  After reviewing the XQuery spec I've come the conclusion that
it is very flexible on the use of whitespace. Two designations, explicit and
significant, may be assigned to productions. Explicit states that any
whitespace allowed in the production must be stated. Significant states that
whitespace is allowed and must not be discarded.

The end result is that for everything else "whitespace may freely be added
between terminals..." but it is apparently not required. In addition, the
preference in lexical analysis is for the longest possible valid match.

So... the following would appear to be a valid xquery expression: 

for$x in document("foo")/item stableorderby$x/size return$x 

because 

1) There is no requirement for whitespace between keywords and variable
references 
2) stableorderby can be represented by the grouing of terminals denoted by <
"stable" "order" "by"> which again has no requirement for whitespace between
terminals.

So our questions are (1) is this correct?  and (2) is this what people
expected? 

Kevin Jones 
Received on Tuesday, 2 September 2003 16:52:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:56:49 UTC