On Fri, Feb 04, 2005 at 12:42:45PM +0100, Kjetil Torgrim Homme wrote:
I've updated the document and made quite a few changes, although they
are all editorial.
Document: draft-ietf-sieve-variables-01.txt University of Oslo
Hi-
I would like to include by reference, without going on about it further
here, my earlier remarks about choices of keywords that might be likely
to collide with future language enhancements. Those issues are still
important, if only to me.
Also I have a few new niggling comments, as follows.
3.
> "When a string is evaluated ..."
I'm not sure that the concept of evaluating a string has been
introduced, so the "when a string is evaluated" is not strictly clear
(even if everybody probably knows what it means). So perhaps lay the
groundwork of saying that this extension enables interpretation of
strings at the moment they are used during runtime , and then say "when
a string is interpreted..." or just change the word to "interpreted" :-)
3.2. Numbered variables
> For ":matches"...
> The wildcards match as little as possible (non-greedy matching).
Even though I am in favor of this: this is a refinement of RFC3028
(which is silent on the greediness issue). Does this need to be
explicitly stated? I would think this should be an item for 3028bis or
whatever the next SIEVE base draft is, as well. (Being able to specify
the :matches greediness would be a plus.)
> The first string in the list has index 1. If the index is out of
> range, the empty string will be substituted. Index 0 returns the
> number of strings in the list as a decimal number.
Hmm, I glossed over this before. There are other environments
(including typical regex implementations) where it's common to have
submatch 0 represent the entire matched string. Access to the number of
strings is useful, but so is access to the entire match (probably more
so than the number of matches, since that's predictable from the pattern
used). Since it's nice to be consistent with what people might already
be used to, I'd recommend having index 0 be the entire match, and something
else be the count of the matches. Maybe a special ${#} for the number
of matches.
Or keep ${0} as the count, and add something else (e.g. ${*}) as the
complete match string.
4. Action set
> An illegal name MUST cause a syntax error.
"MUST be detected as a syntax error" ? (at compile time? runtime?)
4.1. Modifiers
> More than one modifier can be specified, in which case
> they are applied according to this precedence list, highest value
> first:
I think this has been addressed before, but "highest value" is still
ambiguous because "highness" isn't really an attribute of a number, and
the word "precedence" implies doing things in numeric order, 1, 2, 3.
So some people, if not most people, will think of the "highest
precedence value" as having the smallest numeric value. Maybe:
More than one modifier can be specified, in which case they are
applied in reverse order of precedence value, i.e. from largest to
smallest, according to this table:
I would personally make it smallest value first, but either way as long
as it's clear.
5. Test string
I agree with another commenter's earlier remark that :count is silly.
Unless the intent is to count the number of matches, rather than the
number of strings? It doesn't say that, though-- and I don't really
know why that would be useful, either.
Yours,
-mm-