[GeoJSON] namespaces

[Erik Wilde]

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 |