Alan Kent wrote:
>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 is, unfortunately, true. A CQL parser, in order to be helpful,
should convert CQL to a parse tree with prefixes resolved. With that
parse tree you can of course generate XCQL, but the prefixes within XCQL
would be different and machine generated (since the original prefixes
names are gone).
>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.
>
>
We don't use XCQL much. If anything, it's good as a debugging tool.
Something that expresses the parsed CQL as a tree which is then viewed
as XML.
>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.
>
>
I share you view on this.
>This means the XCQL is closer to a cannonical representation of a CQL query.
>
>
Yes.
>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.
>
>
Most of the things was defined/discussed around 12-20 nov 2002. In
summary are three ways. I'll try to illustrate with an example:
>p1 >p2 a and b
1) make prefix a construct of it's own. In this case it would appear
exactly as put in CQL.
<prefix>
<name>p1</name>
<identifier>uri1</identifier>
<prefix>
<name>p2</name>
<identifier>uri2</identifier>
<triple>
<boolean>
<value>and</value>
</boolean>
<leftOperand>
<searchClause>
<index>p1.ti</index>
<relation>
<value>=</value>
</relation>
<term>a</term>
</searchClause>
</leftOperand>
<rightOperand>
<searchClause>
<index>p2.au</index>
<relation>
<value>=</value>
</relation>
<term>b</term>
</searchClause>
</rightOperand>
</triple>
</prefix>
</prefix>
2) make prefixes construct with one or more prefix names in it.
<triple>
<prefixes>
<prefix>
<name>p1</name>
<identifier>uri1</identifier>
</prefix>
<prefix>
<name>p2</name>
<identifier>uri2</identifier>
</prefix>
</prefixes>
<boolean>
<value>and</value>
</boolean>
<leftOperand>
<searchClause>
<index>p1.ti</index>
<relation>
<value>=</value>
</relation>
<term>a</term>
</searchClause>
</leftOperand>
<rightOperand>
<searchClause>
<index>p2.au</index>
<relation>
<value>=</value>
</relation>
<term>b</term>
</searchClause>
</rightOperand>
</triple>
3) expand prefix at term and put in in a separate element "uri".
<triple>
<boolean>
<value>and</value>
</boolean>
<leftOperand>
<searchClause>
<uri>uri1</uri>
<index>ti</index>
<relation>
<value>=</value>
</relation>
<term>a</term>
</searchClause>
</leftOperand>
<rightOperand>
<searchClause>
<uri>uri2</uri>
<index>au</index>
<relation>
<value>=</value>
</relation>
<term>b</term>
</searchClause>
</rightOperand>
</triple>
SRW 1.0 uses method 2. Method 3 is the canonical. 1 was my suggestion at
the time. Method 3 is appealing. In particular it is an excellent way of
representing a query in a backend (DOM).
>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.
>
>
One of the reasons that XCQL has not been on the "hot-list" of topics
lately is that it is not used much (if anywhere).
>Alan
>
>
>
|