[GeoJSON] namespaces

[Stefan Drees]

Hello Erik,

On 18.05.13 18:59, Erik Wilde 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 is there, that is all have a similar itch, but as usual tend to 
scratch in different ways ;-)

Since 2006 there have been work arounds and proposals, most inband of 
course have to ban a specific character (or two) from "normal" values to 
signal a namespace qualifier like the dot (classic):

// ...
of.heck.my.a.namespace.id.foo: "bar"
// ...

or prefixing with a curly braced id like in:

// ...
{http://my.heck.of/a/namespace/id/}foo: "bar"
// ...

or later outband solutions (like JSON Hyper Schemas) targeting the 
transport layer (assumed to be mainly HTTP family protocols allowing:

Content-Type: application/schema+json; 
schema=http://my.heck.of/a/namespace/id
{ // ...
foo: "bar"
// ...

or combinations with even keywords like "extends" or generally warpping 
every thing into a "properties" key'd JSON object ...

As stated in the other processing model threads' response of mine and 
today we live in interesting times :-)

I am willing to wait. Many other JSON consumers and producers grow their 
own workarounds in the absence of a common accept(able|ed) "jsonic" 
standard.

As GeoJSON has the wonderfull heritage, that

A) it **is** widely used as interchange format and that

B) it's domain specific geometry datamodel (for naming important 
entities and declaring their normative ingredients) seems to perfectly 
fit well an ever growing number of large producers (like Google Maps 
Engine and Open Data and ...)

we might as well wait with namespacing for a standard to come up and 
even input our knowledge and needs from GeoJSON into the proposed json 
IETF working group discussions.


>> 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.

Yes, at least XML namespaces are here to stay ;-)

>> 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.

I propose a minimal token, as I understood from the discussions, that 
already other dialects submit geo data in JSON containers, there should 
be a better way, than guessing in natural languages, which language 
might be spoken. In machine languages we like an unambiguous token that 
sets context clear.

If we say: Later, let's concentrate on finishing the GeoJSON we know and 
love plus/minus really minor cosmetics and removal of proven problematic 
parts into a first revision of a submitted I-D I am all for that.

>>>> 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.

Ok. But regardless of their relation: in the end including any or both 
of the aspects "namespacing" and "processing expectations" might hamper 
a fast and clear submission of a GeoJSON I-D. Right?

> cheers,
>
> dret.
>

All the best from sunny Bonn,

Stefan.