991521 - Implement the JSON-LD API

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, enhancement)

Description

[Markus Lanthaler]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; OfficeLiveConnector.1.5; OfficeLivePatch.1.3; .NET4.0E; rv:11.0) like Gecko

Steps to reproduce:

Tried to use the JSON-LD API, it is not available.


Actual results:

The JSON-LD API is not available.


Expected results:

The JSON-LD API as specified at http://www.w3.org/TR/json-ld-api/ is available.

Comment 1

[Boris Zbarsky [:bzbarsky]]

It's not clear to me that we want to implement this in its current state.  For one thing, all the parts that we might actually be using to expose the behavior are explicitly non-normative, and are not defined clearly enough to actually be implementable.

Furthermore, the spec fails some basic API design criteria that should be enforced for new APIs.  For example, it's rejecting Promises with non-Error values.

Comment 2

[Anne (:annevk)]

Also, we are not interested in RDF APIs.

Comment 3

[Markus Lanthaler]

(In reply to Boris Zbarsky [:bz] (on PTO, reviews are slow) from comment #1)
> It's not clear to me that we want to implement this in its current state. 
> For one thing, all the parts that we might actually be using to expose the
> behavior are explicitly non-normative, and are not defined clearly enough to
> actually be implementable.

Could you elaborate a bit on what's not defined clearly enough so that we can improve it in future versions?


> Furthermore, the spec fails some basic API design criteria that should be
> enforced for new APIs.  For example, it's rejecting Promises with non-Error
> values.

Both you and Anne had a look at the design but back then Promises were still very much in flux.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> Could you elaborate a bit on what's not defined clearly enough

A simple example is http://www.w3.org/TR/json-ld-api/#widl-JsonLdProcessor-compact-Promise-any-input-JsonLdContext-context-JsonLdOptions-options step 2.  "dereference" is not a concept that really exists in the web platform.  Presumably this should be a fetch, but then you need to pass in the various arguments the fetch algorithm requires.

In that same step, what happens if there is no transport-provided content type (e.g. if the IRI is a file:// one)?

In step 3, the "currently being processed document" concept is not defined.  If script in document A calls the JsonLdProcessor.prototype.compact function from document B and passes it a JsonLdProcessor object from document C, which one is "currently being processed"?

In step 4, how is "having an @context member" determined?  Is it typeof(expandContext.@context) != "undefined"?  Is it "@context" in expandContext?  Is it expandContext.hasOwnProperty("@context")?  Is it Object.prototype.hasOwnProperty.call(expandContext, "@context")?  Is it something else (like the canonical value of Object.prototype.hasOwnProperty being used)?

Since step 4 can run arbitrary script from the page, you can't really do it asynchronously without defining things like script entry points and whatnot (this is a common issue with specs trying to use promises but calling back into the page in the async portion of the algorithm).

I stopped there, but so far literally every single part I just looked at except for "create a new Promise and return it" is underdefined.  I'll assume that the "create a new Promise" bit is defined by some other spec, since that's the general plan anyway.

If you want to improve this stuff, please get it reviewed by an actual implementor or three; this is why we have the implementation requirements before going to REC normally.

Oh, and while I'm here the JsonLdContext type is invalid WebIDL.  That's even ignoring the fact that it's using deprecated IDL array types.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Both you and Anne had a look at the design

Oh, forgot this bit.  I did?  I don't recall seeing the IDL in this spec before, much less the processing steps in section 11.