W3C home > Mailing lists > Public > www-ql@w3.org > October to December 2002

SchemaImport lexical and semantic problems

From: Mike Sample <mike_sample_ca@yahoo.com>
Date: Fri, 22 Nov 2002 14:27:22 -0800 (PST)
Message-ID: <20021122222722.81377.qmail@web14507.mail.yahoo.com>
To: www-ql@w3.org

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

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

Mike Sample

Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
Received on Friday, 22 November 2002 17:27:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:15 UTC