<div dir="ltr"><div dir="ltr">On Fri, 12 Apr 2019 at 23:41, Graeme Fitzpatrick <<a href="mailto:graemefitz1@gmail.com">graemefitz1@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Yes, we see this with some of the camping grounds we regularly go to. Some have offices / kiosks, where you check in on arrival; some have no check in requirements at all - you just arrive, pick a (unmarked) spot & set up; while others have to be booked online before you go.<div class="gmail_quote"><div><br></div><div>These could probably all be covered by check_in=yes / no / online_only, possibly together with a bookings=(url)?</div></div></div></blockquote><div><br></div><div>I expressed myself badly.  iD can come up with some multi-choice mechanism for check_in, just</div><div>as it does with car servicing types.  Not a problem.  The problem is when airport checkins can</div><div>be any (or all) of A, B, C and D but camping ground checkins can be any (or all) of D, E and F.</div><div><br></div><div>The easy fix is to offer A, B, C, D, E and F for check_in=*,  But that means people could (and</div><div>inevitably will) choose E and F for airport checkins where they don't apply and chose A, B and</div><div>C for camping ground checkins where those don't apply.  Because the list they're offered has</div><div>all of the options (and therefore, they think, all are applicable).  Nobody wants that.  But extra</div><div>code (harder to maintain) is involved in only offering the right values for check_in=* depending</div><div>on the main key (or, far harder still, on the main key of the enclosing area).</div><div><br></div><div>Hence namespacing.  Then the list of offered values for camp_site:check_in (or whatever it</div><div>gets called) is D, E and F; the list of offered values for airport:check_in (or whatever) is</div><div>A, B, C and D.  If you really insist, you can type anything you want into the value, but you'll</div><div>be offered the appropriate preferred values, and are less likely to get it wrong.<br></div><div><br></div><div>Only if you can guarantee that the same set of values for check_in=* will be appropriate for</div><div>all circumstances (and for all time) where it will be used can you avoid having to namespace.</div><div>With check_in=* you can probably do that.  With some of the others you probably can't.<br></div><div><br></div><div>At least that's what I understood the reasoning to be the last time the lead programmer of iD</div><div>had things to say about covered=* and phone booths.</div><div><br></div><div>-- <br></div><div>Paul</div><div><br></div></div></div>