Clarify language in JsonLdProcessor API

[kasei]

Is the language in section 9.1 The JsonLdProcessor Interface normative? In particular, the language about asynchronous evaluation seems like a very specific detail to impose on all implementations. While the use of Promises may make the definition clearer in the context of javascript, I'd appreciate consideration on whether this is really meant to dictate the approach used to implement the spec in all languages.

[gkellogg]

The text is normative, and the "asynchronous" provision is not meant to require that code be run in parallel, but deferred, and possibly done asynchronously.

IMO, saying the an interface is asynchronous is meant to give license to implementations to run parts in parallel, in particular, fetching of remote contexts. I don't see that this requires implementations to run things in parallel, or to yield control while executing.

The "asynchronous" language goes back to the 1.0 specification, so there's really no change here.

I would consider that if we changed the wording to be "deferred" that would be an editorial change, as it's clear that we are simply describing some of the details of a Promise inline.

[kasei]

I guess my concern is that it feels overly burdensome to enforce an asynchronous implementation. If it's normative, how would you even test that it's actually implemented asynchronously? If I'm implementing in a language where it's much more natural to have a synchronous implementation (but presents with the same API returning a Promise backed by an already materialized result/error), why should that be deemed non-conforming? Is there any substantive reason why the processing has to be deferred?

[gkellogg]

I don't see that this requires an asynchronous implementation, and it is certainly not needed to be conformant. In any case, WebIDL is really only useful for JavaScript, and Promises are a JavaScript artifact (although there are other implementations).

My own Ruby implementation is synchronous, and generally follows the algorithmic steps of the API, but does not, in fact, return until it's completed.

The problems is that WebIDL is the only reasonable way to define APIs in W3C specs, and it includes the use of Promises. We don't really have a way to define an API otherwise. The section is normative, as the steps defined there are normative, and consistent with the way that WebIDL APIs are defined (IMO). Perhaps a note that describes this would be satisfactory?

Note: this API is defined using WebIDL and Promises and describes an asynchronous or deferred implementation style consistent with this definition language. Implementations may chose to implement in an appropriate way for their native environments as long as they generally use the same methods, arguments and options and return the same results.

[kasei]

I would very much appreciate such language being added. Would you consider using RFC2119 styling for the word "may"?

[gkellogg]

If this is added to a Note, than RFC2119 MAY would have no bearing; that bit would need to be outside of the note.

[azaroth42]

Discussed on call and resolved by #221.