[OSM-talk] Users, contributors and developers

Andy Robinson Andy_J_Robinson at blueyonder.co.uk
Fri Apr 27 11:26:31 BST 2007


Please excuse my slip-up by talking tables rather than columns in my post
below.

Cheers,

Andy

Andy Robinson
Andy_J_Robinson at blueyonder.co.uk 

>-----Original Message-----
>From: talk-bounces at openstreetmap.org [mailto:talk-
>bounces at openstreetmap.org] On Behalf Of Andy Robinson
>Sent: 27 April 2007 11:23 AM
>To: 'SteveC'
>Cc: 'OSM'
>Subject: Re: [OSM-talk] Users, contributors and developers
>
>SteveC [mailto:steve at asklater.com] wrote:
>>Sent: 27 April 2007 9:45 AM
>>To: Andy Robinson
>>Cc: 'Frederik Ramm'; 'OSM'
>>Subject: Re: [OSM-talk] Users, contributors and developers
>>
>>
>>On 27 Apr 2007, at 09:28, Andy Robinson wrote:
>>
>>> SteveC wrote:
>>>> Sent: 27 April 2007 9:27 AM
>>>> To: Frederik Ramm
>>>> Cc: OSM
>>>> Subject: Re: [OSM-talk] Users, contributors and developers
>>>>
>>>>
>>>> On 27 Apr 2007, at 00:35, Frederik Ramm wrote:
>>>>> Hi,
>>>>>
>>>>>> Now I just wanted people to be able to have
>>>>>> some third attribute, I don't super mind what it's called. I came
>>>>>> away super frustrated that we couldn't even agree having it was a
>>>>>> good idea.
>>>>>
>>>>> It's just different mentalities really. Some (including you) say
>>>>> "let's put that in, I think people are going to put it to good use
>>>>> somehow", others say "if you can't say how it should be used, then
>>>>> leave it out because it will only add to the confusion... even
>>>>> though we would like to have it...".
>>>>>
>>>>> It is true that introducing a "third column" without exact specs on
>>>>> how to use it will add to the confusion. But that's not necessarily
>>>>> a bad thing because out of the confusion my arise a better spec
>>>>> than could have been provided beforehand. (May, not will; you never
>>>>> know where you get with those community processes.
>>>>
>>>> What confusion? And there is a clear use-case - namespaces.
>>>>
>>>
>>> For the laymen amongst us (myself included ;-) ) can someone
>>> concisely give
>>> the reasons that suggest a third column over and above the use of
>>> namespaces?
>>
>>We were talking about the order and the name of what in database
>>terms is just a third column (in addition to key and value). So
>>should it be called namespace or subkey or what and in what order
>>should it be given?
>>
>>eg
>>
>>namespace:key=value
>>eg en:name:blah street
>>
>>or subkey?
>>
>>key:subkey=value
>>
>>name:de=blahstrasse
>>
>> From the database POV it really doesn't matter but for those who see
>>the keyval system as 'chaos' it's all deeply significant. We couldn't
>>even agree that a third column was _needed_. Andy speaking from the
>>front lines would it be useful if it existed?
>>
>
>We are using namespaces now, so presumably the key table simply currently
>holds "namespace:key". Now that's fine and dandy for a simple namespace but
>does it extend well? There is no doubt that whether it's a subkey or a
>prekey we are going to want more depth capability within the tags to make
>better use of a key structure, even if the structure is informal. But if we
>define the structure in xml to separate out en: and name: / key: subkey etc
>before they are joined up to drop into the keys table is there any need to
>have more than one? If the cool feature of searching and filtering at the
>API level can be done better with a third table then go for it, if the
>overhead doesn't really gain us much why bother?.
>
>Hope I'm not over simplifying things here.
>
>Cheers
>
>Andy
>
>Andy Robinson
>Andy_J_Robinson at blueyonder.co.uk
>
>>have fun,
>>
>>SteveC | steve at asklater.com | http://www.asklater.com/steve/
>>
>
>
>
>
>_______________________________________________
>talk mailing list
>talk at openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk






More information about the talk mailing list