[GeoJSON] processing model

[Erik Wilde]

hello stefan.

On 2013-05-19 07:32 , Stefan Drees wrote:
> Currently a proposed json WG
> (http://datatracker.ietf.org/doc/charter-ietf-json/) at IETF is on its
> way chartered as first and only defined step targeting to correct the
> shifted situation, that many standards have begun to refer to JSON RFC
> (even ECMA Script spec) but the JSON RFC points to ECMA spec. THus move
> JSON RFC to standards track and like we plan with GeoJSON make a few
> minor modifications ;-)
> Also, looking at: http://datatracker.ietf.org/wg/json/ I find the
> following active internet drafts (as of 2013-05-19):
> Some of them do look very promising and I feel I should read those
> before sticking my nose further into a debate on schema validation of
> JSON :-)

following JSON activities is one of my hobbies, so yes, there is a lot 
of stuff going on. but so far, there is no consensus on pretty much any 
layered format spec (but at least JSON Patch and JSON Pointer are now 
RFCs, which is great). so there's nothing to build on in terms of 
namespaces or schemas, which might change at some point in time, but 
afaict, not in the next couple of months.

>> great, that's all i was asking for. that allows producers and consumers
>> to understand the expectations. it also allows things such a
>> "validators" to exist where people can submit their GeoJSON, and it
>> might tell them "yes, i can find the data that MUST be present, but i
>> also see data in places where there really SHOULD NOT be any."
> I am interested in helping to provide such a service, though maybe not
> to operate it ;-)

but the question is: can you build such a service, that for everybody 
can answer the question: yes, this makes sense, or no, don't expect this 
to work well. if you can build such a thing, it is basically an 
implementation of the processing model.

>> done, but namespaces imho are simply a part of a processing model, if
>> you want to have a well-defined extensibility model.
> we may well decide to merge the topics at anytime, but I find it good to
> separate the topic of Identity and scope (namespace, fence, scope, ...)
> from processing assumptions to have a better position in what to combine
> and what to separate in the final specification.

while these issues are associated, it may make sense to stay away from 
the namespaces (because there simply is anything to build on, 
currently). but as suggested earlier, i think an explicit processing 
model would be very useful, and not very hard to document.

cheers,

dret.