On 12/4/12, Gary Martin <[email protected]> wrote:
> Hi,
>
:)
[...]
>
> The addition of a greater variety of keywords (metatags) does seem a
> great idea.
+1
[...]
>
> The character we use to mark these is of no great consequence to me but
> there may be advantages to retaining consistency with that form. On
> which note we may as well add 'user' as a synonym for 'me' and 'my'.
we could consider
- user:username
- me
- user:me
- assigned:me , owner:me
... and a different separator char e.g. =
>
> The helper functions are perhaps where I got this impression. The syntax
> for these seems interesting as well. Is the suggestion there that we use
> something like
>
> >>> querystring = '1weekago'
> >>> m = re.search('(?P<n>\d+)weeks?ago',querystring)
> >>> int(m.group('n')) if m is not None else 0
> 1
>
> to discover relatively simple numeric arguments? Is that considered to
> be better than a weeksago(N) style?
>
like I said before I've been working on something like this few weeks
ago for TracGViz plugin . I've been implementing a parser for Google
Visualization API Query Language in gviz_ql branch [1]_ ... which is a
SQL dialect operating on flat data tables (i.e. columns + rows) .
Something like that has been mentioned in BEP 4 btw .
Well , to the point ... In there there is a chance to use date ,
datetime and timeofday literals [2]_ . They seem to be more powerful
in the sense that expressions like this are possible
- dateDiff(startDate, now()) < 30 (i.e. 1 month ago)
- dateDiff(startDate, date "2012-12-05") < 90 (i.e. days
covered by recent december IPMC status report)
- startDate < date "2008-01-01" and endDate > "2012-01-01"
> I like the idea of including ranges and the ability to define open and
> closed intervals for ranges. If we are already able to make that
> distinction, I would probably also add the ability to mix open and
> closed syntax so you can include at one end of the range and exclude at
> the other. I am also considering whether we should get a bit closer to
> open and closed interval notation in sets if that is not too confusing
> for users.
>
of course , as a matter of legibility we could introduce timestamp
literals as well and make them look like
- dateDiff(startDate, now()) < 1 month
- dateDiff(startDate, date "2012-12-05") < 3 months
- dateDiff(endDate , startDate) > 2 years
or other similar literals .
> Finally, for now at least, it may also be worth making sure we have
> operator precedence defined in that document for completeness.
>
+1
I'd also suggest that it'd be nice to structure the syntax using
clauses + operators , similar to SQL . That'd allow us to write a fast
one-way parser for search expressions (preferably an operator
precedence grammar ;) .
[...]
.. [1] GViz QL parser for TracGViz plugin
(https://bitbucket.org/olemis/trac-gviz/src/61393f2d74e2/?at=gviz_ql)
.. [2] Query Language Reference (Version 0.7) #Literals
(https://developers.google.com/chart/interactive/docs/querylanguage#Literals)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
