[Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Ilpo Järvinen]

On Wed, 19 Sep 2012, Eckhart Wörner wrote:
> Am Dienstag, 18. September 2012, 23:15:57 schrieb Rob Nickerson:

> > Variable parts in keys will also lead to an undesired
> > proliferation of unique keys.
> 
> This is the only argument that is not completely broken, and it has two 
> sides: the Extended Conditions proposal has a moderate amount of keys 
> and a moderate amount of values. The Conditional Restrictions proposal 
> has a tiny set of keys and an insane amount of values. Do the math. 

With this proposal I can still pick the key I'm interested in from 
rather small set of keys. And I know what I'm talking here... Somebody 
around here has been doing some traffic volume counting and now all those 
different times put into the keys basically occupy most of the key space 
already (in fact e.g. ITO won't even show all keys anymore because they're 
so many which would obviously be fixable in that particular case as long 
as the browsers can handle such insanely long lists but still highlights 
my point about key space explosion beyond what was considered "sensible" 
upper limit by somebody). I don't find it useful to have a semi-large key 
and semi-large value space instead of sensibly small key space and 
insanely diverse value space per key. I can only image what your proposal 
would cause when all those different times would be put to all keys 
instead of just one.

> > * Avoids the requirement for problematic characters in the key such as "<"
> > or ">"
> 
> Which is a huge problem for data consumers that process XML using 
> regular expressions, and nobody else. 

This is a false claim. I've seen e.g. misdecoded ampersand just too many 
times here and there. And I doubt that such services had anything to 
do with regexp.

> > * Possibility to combine conditions using operators.
> 
>  or more specifically, the AND operator, which has already been a key 
> element in the Extended Conditions proposal.

Now you're arguing bothways. Extented conditions wanted to get rid of 
such operator and use multiple keys instead of an operator. The use of a 
_real_ operator prevents the key space explosion which you hold so dear, 
so no, extented conditions does not have operators in the same sense this 
proposal has.

-- 
 i.