JSON-LD Features at Risk

From RDF Working Group Wiki
Revision as of 20:24, 9 July 2013 by Mlanthal (Talk | contribs)

Jump to: navigation, search

These features of JSON-LD 1.0 were marked "at risk" in a published JSON-LD 1.0 specification. This means that the Working Group identified them as features which might be removed in the future, based on new information (including a lack of evidence of implementations), as described in the W3C Process Document.

@base keyword

Support for the @base keyword might be removed from JSON-LD 1.0 if implementation experience reveals that the fact that a document may have multiple base IRIs is confusing for developers. It is also being discussed whether relative IRIs are allowed as values of @base or whether the empty string should be used to explicitly specify that there isn't a base IRI, which could be used to ensure that relative IRIs remain relative when expanding.

In the 11 April 2013 LC WDs: json-ld and json-ld-api

Resolution: Relative IRIs are allowed us values of @base. The empty string is interpreted as a relative IRI. Setting @base to null to specify that there is no base IRI.

See also https://github.com/json-ld/json-ld.org/issues/223

Reverse properties

Reverse properties might be removed from JSON-LD 1.0 if implementation experience reveals problems with supporting this feature.

In the 11 April 2013 LC WDs: json-ld and json-ld-api
In the 16 May 2013 LC2 WD: json-ld-api

Resolution: Support reverse properties in JSON-LD 1.0.

Allow blank nodes to be used as graph name or property

RDF does not currently allow a blank node to be used as graph name or property, while JSON-LD does. JSON-LD-RDF Converters can work around this restriction, when converting JSON-LD to RDF, by converting such blank nodes to IRIs, minting new "Skolem IRIs" as per Replacing Blank Nodes with IRIs of [RDF11-CONCEPTS]. Based on feedback from implementors the Working Group may decide to disallow blank nodes as graph names and properties in JSON-LD. If this change would affect you, be sure to send in a comment.

In the 11 April 2013 LC WDs: json-ld and json-ld-api
In the 16 May 2013 LC2 WD: json-ld-api

RDF has been updated to allow blank nodes to be used as graph name.

Converting list of lists to JSON-LD

In the interest of space and simplicity, the steps necessary for handling lists of lists have been omitted. Such lists and their elements must, recursively, be handled like other lists. Lists of lists can, however, not be represented in JSON-LD using @list; they have to be represented as a set of interlinked node objects using RDF's rdf:first and rdf:rest properties. The Working Group might either require handling of lists-of-lists or forbid them in JSON-LD 1.0. Implementers please send reports of whether you are able to implement handling for lists-of-lists or would instead request such structures be disallowed.

In the 11 April 2013 LC WD: json-ld-api

Resolution: The algorithm was updated to convert lists of lists to expanded form, i.e., list nodes linked together by rdf:rest properties. The @list keyword does not support list of lists.

Use of method overloading to make the options parameter optional

The definition of the JsonLdProcessor interface uses method overloading to make the "options" parameter optional. According to the current version of the Web IDL specification [WEBIDL], this would not be supported as the "options" parameter (a dictionary) and the callback parameter (a callback function) are not distinguishable. A bug report has been already been filed. If it turns out that this is not a bug, the Working Group may change the interface by swapping the "options" and "callback" parameter.

In the 11 April 2013 LC WD: json-ld-api

Resolution: The API has been updated to use Futures instead of callbacks which means that method overloading is not needed anymore as the callback parameter was eliminated.

See also https://github.com/json-ld/json-ld.org/issues/238 and https://github.com/json-ld/json-ld.org/issues/240

Default value of base member in JsonLdOptions

The default value of base in JsonLdOptions implies that all IRIs that cannot be compacted otherwise are transformed to relative IRIs during compaction. To avoid that data is being lost, developers thus have to store the base IRI along with the compacted document. Based on implementer feedback, the Working Group may decide to change the default value to null, meaning that IRIs are not automatically compacted to relative IRIs.

In the 11 April 2013 LC WD: json-ld-api

Resolution: The base member of JsonLdOptions has no default value. It is only taken into consideration if it was set explicitly.

See also https://github.com/json-ld/json-ld.org/issues/223

Conversion to/from JSON Native Types

JSON-LD-API allows certain RDF literals to be mapped to JSON numbers (if the "use native types" flag is set). The mapping rules

are currently being debated as is which JSON-LD API methods the "use native types" will have an effect in. There may be changes made to the

algorithm and API based on feedback during the Last Call. Implementers and reviewers should keep a close eye on the details for this mechanism.

In the 16 May 2013 LC2 WD: json-ld-api

Resolution: The default value of the useNativeTypes flag is set to 'false' in the JSON-LD API. Explanatory text is added to the JSON-LD API specification explaining the risks of the useNativeTypes flag and how to do proper conversion to/from native types using the to/from RDF method call.

See also: http://www.w3.org/2011/rdf-wg/track/issues/129

Properly referencing the DOM Futures spec

The JSON-LD API specification currently only refers to the "Future" interface and does not attempt to provide any details on the specific implementation of Futures. That is, it does not reference whether or not '.then()' must be specified. This is done in order to allow for some implementation flexibility in the event the DOM Futures spec changes (which the editors of the specification have asserted that the interface is ready to be incorporated into specifications).

The issue relates to how to properly refer to a spec living in the WHATWG as a living standard as well as how to ensure that the interface provided by the spec is stable.

In the 16 May 2013 LC2 WD: json-ld-api

See also: http://www.w3.org/2011/rdf-wg/track/issues/130 and http://lists.w3.org/Archives/Public/public-rdf-wg/2013May/0260.html