[GeoJSON] namespaces

[Allan Doyle]

These discussions are interesting, but I think should be seen as non-essential towards the goal. I get concerned when the emails start being longer than the specs. 

I hope that what comes out of this process is a GeoJSON that (a) has no CRS problems, most likely by eliminating the crs element and (b) has a little bit of text helping people with the parts they have trouble with - mostly the fact that additional elements are allowed.

Beyond that, the effort risks falling into a world of good intentions gone bad.

	Allan

On May 18, 2013, at 12:59 PM, Erik Wilde <dret at berkeley.edu> wrote:

> hello stefan.
> 
> thanks for your comments.
> 
> On 2013-05-17 23:28 , Stefan Drees wrote:
>> On 18.05.13 07:37, Stefan Drees wrote:
>>> On 18.05.13 00:05, Erik Wilde wrote:
>>>> well, that's not entirely true as somebody's naming choices might
>>>> collide with the naming choices of somebody else out there. however,
>>>> while XML has well-established ways of how to handles this in a
>>>> well-defined way (namespaces), JSON doesn't, but the general consensus
>>>> seems to be that people don't want to invent namespaces for their JSON
>>>> format.
>> I guess the latter statement about JSON and namespaces is at least
>> debateable in its meaning and its distribution assertion is losing grounds.
> 
> let me be precise, then: there is no standard for namespaces in JSON, and defining robust namespace mechanisms is not an easy task. so it's a good idea to think hard before you're starting to to that.
> 
>> The need and urge for namespacing ("fences") in JSON is growing IMO, as
>> javascript on client and server side alike spread fast and also JSON as
>> a light and versatile data container has been accepted by many wider
>> "audiences" / communities each having their own shared "vocabularies".
> 
> i completely agree that namespaces are a valuable mechanism, and i never understood why so many people make a hobby out of hating XML namespaces. they serve a useful purpose and may not be pretty, but they work. that being said: it took quite a while to get namespaces done in XML, and there's a lot of value to have them in the XML stack now, because pretty much all the XML machinery you can use these days knows how to handle them.
> 
>> In JSON due to security considerations, you are adviced (as a service
>> provider) to distribute your messages inside an outer wrapper object (to
>> guard against attacks appending elements to a JSON array as outer
>> element). So inside such a message all members sit inside one root
>> object, which implies without further knowledge of what actually
>> constitues the "thing" there is a need for a) well-chosen unambiguous
>> names or b) prefixes where I see many reasons for the latter (b) and
>> only few (as also concluded above in the "naming choices" part) for the
>> former (a).
> 
> all i was trying to say is that you are proposing to invent your own namespace mechanism here, and it may make sense. it's just one more thing that will have to end up on the "processing model" list (see my follow-up email) instead of just being covered by existing standards.
> 
>>>> and "mustIgnore" really isn't part of JSON. it's just part of the
>>>> processing model of most JSON-based representations (and often more
>>>> implicitly than explicitly so). i think it would help a lot to make the
>>>> processing model explicit and define how GeoJSON is supposed to be
>>>> consumed.  ...
>>> IMO it is necessary to draw a line between the two positions mentioned
>>> here as a mere indication where the responsibility of the GeoJSON I-D
>>> ends and where the producer-consumer-relationship enforces additional
>>> rules that only depend on the instance pair of the communication channel
>>> and not on the general case.
> 
> well, namespaces and the processing model interact, you cannot completely separate them. just as an example, consider an extension where a producer would add an "coordinate offset" as an extension: all the coordinates would actually need to be adjusted by that offset to be the actual ones. as a client not knowing that namespace/extension, i would misinterpret all coordinates.
> 
> some vocabularies have chosen to introduce "mustUnderstand" semantics, allowing extensions to carry that label which tells consumers that they should stop processing if they don't know that extension. this ability of the format to make that assertion must be built into the format itself (the processing model), or producers cannot make these assertions.
> 
> what i wanted to say is that both the namespace mechanism and the processing model set hard limits on the things that parties can do with the format, and they cannot be changed in hindsight (without breaking everybody who implemented before such a change).
> 
> more on this in the "processing model" follow-up, since you wanted to break up the thread. i do feel that these two issues have a lot in common, however.
> 
> cheers,
> 
> dret.
> 
> -- 
> erik wilde | mailto:dret at berkeley.edu  -  tel:+1-510-2061079 |
>           | UC Berkeley  -  School of Information (ISchool) |
>           | http://dret.net/netdret http://twitter.com/dret |
> _______________________________________________
> GeoJSON mailing list
> GeoJSON at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org