- From: Gregg Kellogg <gregg@kellogg-assoc.com>
- Date: Thu, 6 Oct 2011 17:41:11 -0400
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- CC: Olivier Grisel <olivier.grisel@ensta.org>, Linked JSON <public-linked-json@w3.org>
On Oct 6, 2011, at 7:23 AM, Markus Lanthaler wrote: >> Why so? As the array is ordered, better state that the context is >> processed by strictly following the order disregarding the fact they >> are remote or not. If you want to make sure that local context info to >> be processed last just put it at the end of the array. This is both >> simpler to understand and more expressive: >> >> For instance that would allow JSON-LD producer to define local context >> info with reasonable defaults values to be overriden by a dynamically >> generated remote JSON-LD document. > > Because that's the way it usually works, just think of CSS for example. > > Normally you would define a general remote context with reasonable defaults that you dynamically overwrite locally and not the other way round. E.g. setting the documents language. If the processing rules basically call for substituting a @context IRI with the content of the @context block at the referenced document, then requiring the processor to re-order the array so that referenced contexts are processed before in-line seems un-natural. In reality, I think this is an academic concern, and we can state that best practice is to process the contexts (remote or local) in the order listed. CSS does not define an order except in most-specific to least specific, in-tag or in-document before loaded (AFAIR). JSON does specify an order. In reality, I would expect that there would only be two entries, a remote and a local, but test cases could check for multiple remote and multiple local with order-dependent definitions. Gregg > -- > Markus Lanthaler > @markuslanthaler > > > > >
Received on Thursday, 6 October 2011 21:41:52 UTC