Hi,
XCQL again sorry. I got a reasonable way along implementing a parser, and
then realised my model was not quite right for generating XCQL. I have been
resolving prefixes while parsing the CQL. To generate XCQL it seems
necessary not to resolve them durin parsing - the parse tree needs
to have them retained if I want to generate XCQL from the parse tree.
This lead me to wonder what the XCQL was for exactly. It seems the
prefixes are like XML namespaces. Currently XCQL uses names like CQL
that consist of an optional prefix plus a name (dc.title or title). The
XCQL document also contains prefix declarations.
An alternative way (not necessarily better) of doing things is to not
include prefixes, but rather have the prefixes all expanded. That is, in the
XML have separate <namespace> and <name> (or whatever they should be
called) elements. All prefixes have already been resolved, including
working out defaults.
This means the XCQL is closer to a cannonical representation of a CQL query.
By cannonical, I mean introduction of '( )' in CQL won't change the XCQL.
Introduction of different prefix names wont change the XCQL. Using or
not using double quotes wont change the XCQL. Its not 100% canonical
however as reordering a list of modifiers wont affect query semantics,
but will change the XML rendition.
The current XCQL form requires the XML to be processed to normalize
prefixes to namespace URIs before processing, with default namespace
etc processing taking place. Expanding prefixes would require that all
the prefix->URI bindings be known when converting CQL query into XCQL,
which is not true in the current XCQL form.
I am not pushing for this change, more checking if the current approach
was intensional. Just trying to understand the background and any other
gotcha's with the current semantics. Sorry, there is so much mail on
this list, I thought I would ask instead of going through the 3,700
mail items I have in this mail folder.
My guess is, the current approach is intensional so you can parse a
CQL query into XCQL without knowing all the prefixes that may be in
scope.
Alan
|