> Date: Tue, 2 Sep 2003 12:07:36 +0100
> From: "Matthew J. Dovey" <[log in to unmask]>
> In XCQL the type of term could be relaxed to allow any XML structure e.g.
> <gils:boundingRect xmlns:gils="urn:gils.org:termTypes">
> How to encode in CQL?
> option 1: direct escaped encoding?
> geo.countryBorders within "<gils:boundingRect xmlns:gils="urn:gils.org:termTypes"><gils:point>13N25W</gils:point>..."
CQL itself has nothing to do with XML, so it would be silly -- and
unnecessary -- to apply an XML encoding to the string. There's no
need to protect '<' and '>', which are not special characters in CQL
term strings. But we _do_ need to protect '"', which _is_ a special
character -- the only one, in fact.
So if we go this route at all, we should use
geo.countryBorders within "<gils:boundingRect xmlns:gils=\"urn:gils.org:termTypes\"><gils:point>13N25W</gils:point>..."
(as the existing specification already nails down.)
> option 2: different bespoke string based encoding
> geo.countryBorders within "boundingRect(13N25W,25S70E)"
Fine by me. I think we should endeavor to preserve CQL's design goal
of being human-readable, and this approach is much more conducive to
that goal than embedding an ugly hunk of XML. There's precedent, of
course: XPath is a string-based syntax that very deliberately does
_not_ use XML for reasons of readability.
> Questions: how to ensure that this is recognised as a structure not
> as a string? (or just define this for the particular index
> geo.countryBorders must be a structure of this form).
The proposal already on the table is to define relation modifiers to
indicate the "type" of the term, e.g.
gils.location =/point "34,76"
gils.location within/rect "34,76 36,78"
Works for me.
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "Have you killed anyone?" / "Yes, but they were all bad" --
Arnold Schwartzenegger, "True Lies".
Listen to my wife's new CD of kids' music, _Child's Play_, at