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

[Eckhart Wörner]

Hi Ilpo,

Am Mittwoch, 19. September 2012, 15:45:44 schrieb Ilpo Järvinen:
> > > * 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. 

Example? I have yet to encounter a single OSM tool that does not handle XML correctly.

> And I doubt that such services had anything to 
> do with regexp.

XML is a format explicitly designed for exchange of *arbitrary* data, and libraries that manipulate XML documents go to great effort to ensure stuff like character entities are handled correctly.
The only reason why such errors happen is because some idiots believe that they can handle XML in five lines of code, which normally involves some "clever" regexp'ing.

Apart from that, the argument is flawed anyway because both key and value end up as attributes in the XML, and the Conditional Restrictions proposal has "<" in its values.

> > > * 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.

Extended Conditions does not have an *explicit* AND operator, however, there is an *implicit* AND written as ":".
maxspeed:hgv:(22:00-06:00):forward is the maxspeed that applies if you are in an hgv *and* the time is between 22:00 and 06:00 *and* the relative direction is forward.

Eckhart