Agenda

http://lists.w3.org/Archives/Public/public-linked-json/2013Apr/0023.html

Topics

JSON-LD API and Futures
Term re-definition behavior
Test Suite Design

Resolutions

Address ISSUE-125 by adopting a Futures-based approach for the JSON-LD API.
When re-defining a term 'A', any previous definition for term 'A' is removed before the right hand side for the new re-definition is evaluated.

Chair

Manu Sporny

Scribe

Niklas Lindström

Present

Manu Sporny, Dave Longley, Niklas Lindström, Markus Lanthaler, Gregg Kellogg, Paul Kuykendall

Audio Log

audio.ogg

Manu Sporny: Anything else we need to discuss today? [scribe assist by Manu Sporny]

Dave Longley: We need to discuss terms and term redefinition. [scribe assist by Manu Sporny]

Niklas Lindström is scribing.

Topic: JSON-LD API and Futures

Manu Sporny: this came out of a discussion re. node-callback style vs. future (and web spec) callback style

…: it seems possible to ref. a spec outside of the w3c (whatwg futures)

… most browser vendors intend to use that Future API

... so using nodejs callback style would deviate from this

… dave and Markus have worked on impl. and spec changes to see what switching to Futures entails

Markus Lanthaler: http://www.markus-lanthaler.com/tmp-futures/json-ld-api/#the-application-programming-interface

Markus Lanthaler: not that many changes that had to be made

… dropped the callback signatures and changed the void return type to Future

… the algorithm didn't change at all

… only how the methods are linked to the algorithms

… now you create a future and return it, and then the caller resolves or handles error

…I didn't include much details on Futures, instead decouple that from here and allow the referenced spec to describe the details

Manu Sporny: although anne wanted us to mention some details, but that is now be expressed in this futures-adaptation

Gregg Kellogg: an example could illustrate how this is used

Dave Longley: a danger with that would be that an example would be invalid if the Futures API changes

Markus Lanthaler: the good thing is that that isn't normative though

Manu Sporny: that would be a nice tradeoff; and we can to some extent change examples even after REC

Manu Sporny: and we don't have to to the overloading anymore?

Markus Lanthaler: true

…. error callback also returns a Future; overall no fundamental changes

Dave Longley: what does the load context cb resolve to? the return value used to include final url and data

Markus Lanthaler: now either string error or dictionary with url + context

Dave Longley: http://promises-aplus.github.io/promises-spec/

Dave Longley: futures, based on Promises/A+

… I've looked at something implementing this in JS

… the API is similar to Futures, but not identical

… I went ahead and implemented Futures. Some changes is that previously we could just call the callback, now we have to pass an object [niklasl: did I get that correctly?]

… [dave describes details on the implementation, regarding input and return values]

... I did complete an implementation of Promises/A+; I need to wrap that to make it compliant to the Futures spec. However, it may be that that spec changes to become closer to Promises/A+

Dave Longley: I found it more difficult to use Futures than the node.js continuation-style, but that may be a part of the learning curve. It seems like the Futures spec may be changing and it may be changing closer to the Promises API. [scribe assist by Manu Sporny]

… it's unclear right now. Noone uses this incarnation of Futures yet, apart from us...

Markus Lanthaler: create/fulfil and reject are missing from Promies/A+, need to be added for Futures

Manu Sporny: is this the right direction? It seems clear that we can add this, and that the Futures spec can evolve independently

Dave Longley: from what I can tell, I'd expect that more people with experience will look at the Futures API and demand changes. But it will probably become what ends up in web browsers.

… I don't think people will give up and go with the node callback style. It will end up different from now, but people are used to having a framework for this.

Gregg Kellogg: it seems like a very elegant way of doing things. I'm nervous about using this at this early stage, but it seems like the right direction.

… we seem to be able to handle spec changes of that , unless radical. The test suite must be adapted, but the spec text is ok.

Paul Kuykendall: adding these changes this late in the game, using a spec in such an early stage, is somewhat worrying

Manu Sporny: if we choose to take a path that goes away from the web platform (the browser vendor's POV), it may very well cause problems (with uptake..)

… since this API is targeted to JS impl.s in the browser, this is important

Paul Kuykendall: decoupling this would be good to get further along with the specs

… it would be good to not bind the algorithms to the API

Manu Sporny: that's done now

Gregg Kellogg: but they are bound – they're in the same spec

Gregg Kellogg: if we fail to get to LC due to API instability, the algorithms fail along with that

Manu Sporny: we could split the API out, we need to go to another LC; if we move to futures, same thing

… we don't seem to want to take the no-change route

Markus Lanthaler: also, the current callback style isn't like the callback-style done in browsers

Dave Longley: we also need two independent implementations

Manu Sporny: it could be fairly easy: use the core js impl. . of the algorithms but implement your own Futures on top

Markus Lanthaler: most important to have impls implement the features/algorithms

Gregg Kellogg: it doesn't seem to be required that futures are implemented async.

Niklas Lindström: Regarding any other options - is it possible to have some parts of the API by demanding that the data passed in has previously resolved any fetching of any entities? [scribe assist by Manu Sporny]

Niklas Lindström: This would be a two-pass approach, where every external reference would be resolved. [scribe assist by Manu Sporny]

Manu Sporny: I think we tried to think about that approach, it would be a lot of cognitive load on the developers. [scribe assist by Manu Sporny]

Niklas Lindström: It would be nice to have a mathematically pure transformation that is synchronous... it's sort of beside the point at this stage. [scribe assist by Manu Sporny]

… [it would still have to be async to do the initial loading of external resources]

PROPOSAL: Address ISSUE-125 by adopting a Futures-based approach for the JSON-LD API.

Manu Sporny: +1

Gregg Kellogg: +1

Niklas Lindström: +1

Markus Lanthaler: +1

Dave Longley: +1

Paul Kuykendall: +1

RESOLUTION: Address ISSUE-125 by adopting a Futures-based approach for the JSON-LD API.

Manu Sporny: This decision requires that the JSON-LD Algorithms and API spec must go through a second Last Call.

Manu Sporny: ISSUE-124 is resolved as a result of this resolution - http://www.w3.org/2011/rdf-wg/track/issues/124

Manu Sporny: thus the optionals parameter can be the last, and optional

… I all respond to the interested parties

Markus Lanthaler: do we want to include an example or more prose?

Manu Sporny: both would help

Paul Kuykendall: will both specs go through LC or only algorithms and API?

Manu Sporny: I believe only this; we can continue with Syntax to CR

…. but the test suite uses the algorithms+API; so the Syntax would wait for that

… after LC we could probably go to PR, once we have implementations reports etc.

Paul Kuykendall: just checking the state of things when we base our future on something which is a draft...

Manu Sporny: we do this to increase the chances of browser vendors of adopting this API

Markus Lanthaler: https://github.com/json-ld/json-ld.org/commit/4751e057970d3ca3161cb43c37cd6f7f5c0ef57d

Markus Lanthaler: https://github.com/json-ld/json-ld.org/commit/657c90f3fc4050fce006fa11a2a420e7e4efe049

Topic: Term re-definition behavior

Dave Longley: to recap: this issue is about what the behavior is if you in a new context use a term in the RHS which is already defined. Should it remove the old term def before interpreting of the RHS

… recursion would fail with recursion if the term is completely new...

Gregg Kellogg: [{"term": "a"}, {"@vocab": "b"; "term": "term"}]

Manu Sporny: the last time, a bunch of us seemed to agree that the definition should be reset before the interpretation is done

Markus Lanthaler: it's not a partial redefinition if you just use a term for expansion

… if you delete a term as soon as it is defined you introduce an asymmetry

Gregg Kellogg: re. the above example, this illuminates the choice

Dave Longley: the cognitive load is reduced if we reset the term as soon as it is defined

Markus Lanthaler: do we need to change anything in the algorithms?

Dave Longley: just fix a bug and put some clarification in text in the algorithm

PROPOSAL: When re-defining a term 'A', any previous definition for term 'A' is removed before the right hand side for the new re-definition is evaluated.

Gregg Kellogg: +1

Manu Sporny: +1

Niklas Lindström: +1

Markus Lanthaler: +1

Dave Longley: +1

Paul Kuykendall: +1

RESOLUTION: When re-defining a term 'A', any previous definition for term 'A' is removed before the right hand side for the new re-definition is evaluated.

Dave Longley: the only change in the algorithm is if you redefine a term which looks like a curie (which was brought up initially)

Topic: Test Suite Design

Manu Sporny: basically we're keeping the test suite the same

… for the api, we're going to have developers point to the test harness they use for the api

… we have the approach for both the main syntax-focused suite and the API test suite

Gregg Kellogg: EARL reports for the different manifests is enough to produce the report (in turtle or json-ld)

Gregg Kellogg: the driving manifest will determine the absolute IRIs for the tests

Markus Lanthaler: but locally hosted manifests will then resolve to different IRIs

Gregg Kellogg: perhaps a base would be enough

… the turtle test suite manifest has this problem currently

Markus, Gregg, and Dave Longley will submit implementation reports for a total of 5 implementations.

… digital bazaar will have implementations in js, php and python

... [gregg on negative tests, datatypes, syntax tests]

Manu Sporny: next stage is getting some reports done

... it would be good to get EARL reports from implementors

… the format will be like the turtle reports

Gregg Kellogg: https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/reports/rdf.rb-earl.ttl

Gregg Kellogg: this is the earl report for the turtle tests; the form will be the same

Dave Longley: are we going to generate these reports in json-ld?

Gregg Kellogg: https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/reports/index.html

Gregg Kellogg: the report I use takes test manifests and individual reports; processes as RDF, runs sparql to extract results; and generates a json-ld file from that

JSON-LD Community Group Telecon

Minutes for 2013-04-23

Topic: JSON-LD API and Futures

Topic: Term re-definition behavior

Topic: Test Suite Design