<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Hi Yuri,</p>
<p>We have to decide what is most important - fidelity to the infinite number of tagging styles out there, or the ability to get a basic set of tagging grammar accepted in as many tools as possible.</p>
<p>Any rules grammar will always have limits of course. If the rules are too complex to represent in a declarative way, that is in itself an indication of the mess we have got ourselves into. If the "unwritten rules" of OSM tagging are too complex to write down, then they need sorting out first! Having a simple base to work from might be a good first step. Automated chaos is still chaos.</p>
<p>I agree that the ultimate rules engine may well end up using e.g. JS as a medium to express some of the subtleties of the rules. Once a JS implementation has been published, then people can translate the JS reference implementation into whatever language they need. But separating the basic rules from the execution engine is nothing more than architectural best practice, and there is no reason that the basic rules should not be portable across runtime environments.</p>
<p>Can you think of any complex patterns which cannot (easily) be expressed in a declarative way?</p>
<p>The real challenge here is not for the coders, but a perennial challenge for the OSM community. How do we get to such a consensus about tagging patterns, that we can actually say "this is correct" and "this is wrong enough to warrant correction" without upsetting a large number of people? As soon as a discussion is about right vs wrong, it degenerates into mudslinging.</p>
<div> </div>
<p>//colin</p>
<p>On 2017-12-24 20:37, Yuri Astrakhan wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div dir="ltr">
<div>
<div>
<div>
<div>Declarative rules are usually not very good. Every tool must understand every type of rule, and must be updated when new rule types are introduced. Plus declarative grammar is either too limiting, or eventually starts looking like a scripting language itself, and we end up building an execution environment in every tool. </div>
<div> </div>
<div> </div>
I think a better path is executing scripts inside other languages, e.g.<br />
<div> </div>
<div>* a JavaScript library ran by Java, Python, C++, ...</div>
<div>* a lib that gets compiled into a webassembly for browser, or connected to other languages via native bindings (less tried path)</div>
<div> </div>
The lib would need an API to</div>
* access local data state</div>
* access master OSM DB for additional data</div>
* access other tools like taginfo<br />
<div>
<div>
<div>
<div>
<div> </div>
<div> </div>
<div>Integrating scripting environment may be difficult, but offers far greater benefits of rule consistency and flexibility.</div>
<div> </div>
</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br />
<div class="gmail_quote">On Sun, Dec 24, 2017 at 7:30 AM, Colin Smale <span><<a href="mailto:colin.smale@xs4all.nl">colin.smale@xs4all.nl</a>></span> wrote:<br />
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif;">
<p>The technical differences between java and JS do not preclude generic thinking. Consider tzdata[1] for example, which does something analogous for time zone data.</p>
<p>The "rules database" can be made portable, in the form of XML or JSON for example. The logic for using these rules can be described in a portable way. Then you add a set of compliance tests, and publish a reference implementation to demonstrate that is is possible to implement it. After that, the logic can be implemented in any language you like, checked against the compliance tests and the bindings published.</p>
<p>Externalising the rules database enables updates and customisations for particular reasons. Depending on the specific use case and the associated non-functionals, validation could possibly be offered as a cloud service (not necessarily by OSM).</p>
<div> </div>
<p>//colin</p>
<p>[1] <a href="https://en.wikipedia.org/wiki/Tz_database" target="_blank" rel="noopener noreferrer">https://en.wikipedia.org/<wbr />wiki/Tz_database</a></p>
<div>
<div class="h5">
<p>On 2017-12-24 12:18, James wrote:</p>
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">
<div dir="auto">ID is javascript, JOSM is java. So right there I already see a intercompatibility issue</div>
<div class="gmail_extra"><br />
<div class="gmail_quote">On Dec 24, 2017 6:12 AM, "François Lacombe" <<a href="mailto:fl.infosreseaux@gmail.com">fl.infosreseaux@gmail.com</a>> wrote:<br />
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div dir="auto">Hi
<div dir="auto"> </div>
<div dir="auto">Here is an idea I got regarding tagging validation in editors (iD, JOSM, others).</div>
<div dir="auto">Subsequently to wiki proposal voting and cleanups, it's currently necessarily to open issues in each editor repository to ask for new tagging validation rules. </div>
<div dir="auto"> </div>
<div dir="auto">It can sometimes be time consuming to develop those new rules and such a work is done independently by each project maintainer. While each project have its own specific components, background logic is the same.</div>
<div dir="auto"> </div>
<div dir="auto">Would a new lib called like osmtagvalidator or so in charge of doing conform validation to wiki be useful?</div>
<div dir="auto">It may be shared by any project involved in osm editing and preserve its resources for other valuable developments.</div>
<div dir="auto"> </div>
<div dir="auto">For me, validation doesn't prevent users to use tags they want, but only warn them about possible mistakes.</div>
<div dir="auto"> </div>
<div dir="auto">How would devs and users feel about this?</div>
<div dir="auto"> </div>
<div dir="auto">All the best</div>
<div dir="auto"> </div>
<div dir="auto">François</div>
</div>
<br />______________________________<wbr />_________________<br /> talk mailing list<br /> <a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br /> <a href="https://lists.openstreetmap.org/listinfo/talk" target="_blank" rel="noopener noreferrer">https://lists.openstreetmap.or<wbr />g/listinfo/talk</a></blockquote>
</div>
</div>
<br />
<div class="m_-1038282337528757563pre" style="margin: 0; padding: 0; font-family: monospace;">______________________________<wbr />_________________<br /> talk mailing list<br /> <a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br /> <a href="https://lists.openstreetmap.org/listinfo/talk" target="_blank" rel="noopener noreferrer">https://lists.openstreetmap.<wbr />org/listinfo/talk</a></div>
</blockquote>
</div>
</div>
</div>
<br />______________________________<wbr />_________________<br /> talk mailing list<br /> <a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br /> <a href="https://lists.openstreetmap.org/listinfo/talk" target="_blank" rel="noopener noreferrer">https://lists.openstreetmap.<wbr />org/listinfo/talk</a><br /> </blockquote>
</div>
</div>
</blockquote>
</body></html>