On Fri, 19 Nov 2004, Mike Taylor wrote:
>> Which means that we would just be formalising the CQL naming system
>> into the query language, rather than as an implementation guideline.
> One is that we don't pollute the namespace, because we have a+b+c+d
> axes) rather then a*b*c*d index-names.
Sure, but no one -needs- to know all a*b*c*d indexes, just the ones that
their community/profile has prescribed.
> The second is that, because the refinements are visible at the CQL
> language level rather than only within the opaque string that is index
> name, implementations can do clever things with them.
This is the advantage of the proposal, IMO.
>> So you'd end up with:
>> instead of rec.recordCreationAgentName
> No. In this case, the modifiers are not modifying, but completely
> changing. What would a search on (unmodified) "rec.record" mean? The
> example is a straw horse. A more realistic one would be
No, I just got it back to front:
name of an agent
name of an agent that created something
name of an agent that created the record
You could also have
Date of the creation of the record.
But how is that different to:
>> It further exacerbates Eliot's problem of wanting to support aliases
>> based on existing usage.
> Au contraire. It _solves_ Eliot's problem, because he can use
> dc.creator (enhancing interoperability) while at the same time making
> explicit that he is using "screator" in the specific and somewhat
> different sense that GILS means it.
> dc.creator/gils.creator = azaroth
I thought the problem was more that GILS already has 'record-source'
whereas we want to call it something different.
> However. There is a problem with syntax. Putative index modifiers
> could not take values as relation modifiers and boolean modifiers can,
> because the relation that introduces the value would be ambiguous with
> the relation attaching the modified index to the query term. e.g.
> Conclusion: I still think index modifiers are a cute thing, but
> implementation considerations neuter them by denying them the ability
> to take values;
None of the examples so far have required values. And indeed anything
that does require a value can simply be enumerated. So I don't think that
this is an insurmountable issue.
,'/:. Dr Robert Sanderson ([log in to unmask])
,'--/::(@)::. Dept. of Computer Science, Room 805
,'---/::::::::::. University of Liverpool
____/:::::::::::::. L5R Shop: http://www.cardsnotwords.com/
I L L U M I N A T I