> >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

> 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).

I don't understand why this follows (as my parser doesn't do that :) )


class Prefixed:
   prefix = "dc"
   prefixURI = "http://.../"
   value = "title"

   def __str__(self):
     return "%s.%s" % (self.prefix, self.value)

(Obviously simplified)

Then Prefixed is the parent class for index, relation,
relationModifierName and booleanModifierName ... anything that can have a
prefix.

Then as you go through you can step up looking for prefixes and put the
URI into prefixURI, keeping the user's name in prefix.


> We don't use XCQL much. If anything, it's good as a debugging tool.

Yes.

> >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
> I share you view on this.

The parser may not know how to expand the prefix because it's relying on
the server's defaults from the Explain document.

I don't see a need to change the XCQL, especially as it's not often used.
(apart from to add an element for modifier comparison)  It's not broke,
no need to fix it to something which is just different.

Rob

--
      ,'/:.          Dr Robert Sanderson ([log in to unmask])
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Nebmedes:  http://nebmedes.o-r-g.org:8000/
____/:::::::::::::.
I L L U M I N A T I