W3C home > Mailing lists > Public > www-ql@w3.org > January to March 2003

RE: SchemaImport lexical and semantic problems

From: Todd A. Mancini <todd.mancini@daxat.com>
Date: Tue, 21 Jan 2003 11:38:25 -0500
To: <www-ql@w3.org>
Message-ID: <000a01c2c16b$84c5eb60$0201a8c0@qodfathr>
Was there any public resolution on this matter?  Is "import schema
default element namespace = 'http://example.com'" legal syntax, and will
the grammar be updated to reflect this fact?

 

            Thanks,

            -Todd

 

-----Original Message-----
From: www-ql-request@w3.org [mailto:www-ql-request@w3.org] On Behalf Of
Mike Sample
Sent: Friday, November 22, 2002 5:27 PM
To: www-ql@w3.org
Subject: SchemaImport lexical and semantic problems

 


I scanned the issues list and didn't see this.  There are two
problems with the SchemaImport in the Nov and earlier XQuery
WD, one lexical and one semantic.

The lexical problem is that parsing:

  import schema default element namespace = "http://example.com"

causes the specified lexer choke at "default". This is because
"import schema" bumps the lexer from the DEFAULT or OPERATOR
lexical state to NAMESPACEKEYWORD state in which neither
<"default" "element"> nor <"default" "function"> are
recognized.  Adding these tokens to the NAMESPACEKEYWORD state
with "maintain state" (no transition) should safely allow the
lexer to handle the given grammar (the tokens don't conflict
with the only exit to the NAMESPACEKEYORD state, a
StringLiteral (i.e. something in quotes). This brings up the
semantic issue: do you really want to be able use a schema
namespace as the default function namespace?

The SchemaImport grammar production in the November WD
references the DefaultNamespaceDecl which allows on make the
schema's URI the default function namespace or the default
element namespace.  Presumably, only the default element
namespace is useful for a schema URI.  This is probably just
an oversight from when the DefaultNamespaceDecl only specified
the default element namespace.

A simple solution is refactoring the DefaultNamespaceDecl
production to be composed of two alternatives,
DefaultElementNamespaceDecl and
DefaultFunctionNamespaceDecl. This would allow the
SchemaImport production to reference the
DefaultElementNamespaceDecl, disallowing the odd situation
described above.  Though the 'element' keyword is implied by
the SchemaImport leaving it explicit may make things slightly
more obvious to those learning XQuery (with the minor benefit
of re-using a grammar production). With this solution only
<"default" "element"> needs to be added to the
NAMESPACEKEYWORD state.


An unrelated nit is that the lexical state transition tables
have a couple of "resetParenStateOrSwitch(DEFAULT)" left in
them but no corresponding pushParenStates. Presumably these are
no longer required now that the FUNCDEF lexical state is
removed (thanks to the "as" token).  On this note, will a
version of the xpath-grammar.xml file updated to the November
WD be available to non-members soon?

Keep up the good work! Kudos to those who eliminated the
expression precedence nasties via the BNF itself for the Aug
WD.

Mike Sample

 

  _____  

Do you Yahoo!?
Yahoo! <http://rd.yahoo.com/mail/mailsig/*http:/mailplus.yahoo.com>
Mail Plus - Powerful. Affordable. Sign up now
<http://rd.yahoo.com/mail/mailsig/*http:/mailplus.yahoo.com> 
Received on Tuesday, 21 January 2003 11:38:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 22 July 2006 00:10:18 GMT