JSON-LD Community Group Telecon

Minutes for 2013-04-09

Agenda
http://lists.w3.org/Archives/Public/public-linked-json/2013Apr/0009.html
Topics
  1. Last Call Documents for RDF WG
  2. ISSUE-238: WebIDL dependency
  3. ISSUE-223: JsonLdOptions base vs. @base
  4. Compaction corner cases
  5. ISSUE-229: Test Suite
Resolutions
  1. Express the WebIDL for functions with optional parameters using the method overloading WebIDL pattern.
  2. If the result of compaction is an array at the top level, always wrap it in @graph (default graph). This means that the result of compaction will always be an object.
  3. When a context is passed into the .compact() function call, it MUST NOT be the 'null' value. If a null value is detected, an error must be thrown.
Chair
Manu Sporny
Scribe
Markus Lanthaler
Present
Manu Sporny, Dave Longley, Markus Lanthaler, Gregg Kellogg, Paul Kuykendall, David I. Lehn
Audio Log
audio.ogg
Manu Sporny: Any updates/additions to the Agenda? [scribe assist by Manu Sporny]
Dave Longley: https://github.com/json-ld/json-ld.org/commit/ddca14bcff5e28491ac1eb0c16414dfc3a5270f2
Dave Longley: There is a proposal there, we should cover that. [scribe assist by Manu Sporny]
Markus Lanthaler is scribing.

Topic: Last Call Documents for RDF WG

Markus Lanthaler: Last Call documents are ready and have been put in place, we have minor issues to deal with regarding the documents.
Manu Sporny: Lets send a mail to the pubrules team for the publication on Thursday
... has the transition request been made?
Markus Lanthaler: I don't know
Manu Sporny: typically the RDF WG chairs need to do that.. not sure they did it
... I will send them an email. We also need to make sure to tell the W3C Chairs that this is happening.

Topic: ISSUE-238: WebIDL dependency

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/238
Manu Sporny: this has to do with the reference that we make to WebIDL
... I was surprised that we are required to do that idlharness thing
Markus Lanthaler: All sorts of specs use this, I think. [scribe assist by Manu Sporny]
Manu Sporny: Dave, you said you try to get this working but there were some issues!?
Dave Longley: yeah... some things can't be implemented in JavaScript.. for example the stringify
... non-writeable/non-enumerable could probably be fixed with the newest ECMAScript
... the other thing was the order of parameters. The optional parameters have to come last
... this breaks most existing JavaScript libraries
Manu Sporny: I don't think we need to change the interface
Dave Longley: http://www.w3.org/TR/WebIDL/#dfn-optional-argument
... we need to do what most JavaScript do not what the idltest requires
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21640
Markus Lanthaler: One option would be to use method overloading [scribe assist by Manu Sporny]
Manu Sporny: ... but that wouldn't work either in WebIDL, a callback isn't distinguishable from a dictionary. That is a bug in WebIDL.
Manu Sporny: ... he advocated to use futures instead of callbacks.
https://github.com/json-ld/json-ld.org/issues/238#issuecomment-16113774
Markus Lanthaler: Here's what a future looks like: proc.expand(input).then(successCB, errorCB);
Markus Lanthaler: Future expand (JsonLdInput input, optional JsonLdOptions options);
Markus Lanthaler: That would make a dependency on DOM4, which we can't do because that's not a REC? [scribe assist by Manu Sporny]
http://www.w3.org/TR/geolocation-API/#geolocation
http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCPeerConnection
Markus Lanthaler: I asked Robin for his preference - he said futures, but we are not going to do that. [scribe assist by Manu Sporny]
Markus Lanthaler: The next thing would be to just use method overloading and ship it even though that means we're shipping it ... (MISSED) [scribe assist by Manu Sporny]
Markus Lanthaler: He said that we should probably just keep what we had. [scribe assist by Manu Sporny]
Markus Lanthaler: If we do method overloading, we'd be depending on a bug in WebIDL. [scribe assist by Manu Sporny]
http://www.w3.org/TR/WebIDL/#dfn-distinguishable
Markus Lanthaler: dictionaries and callbacks are not distinguishable
Discussion about WebIDL and how to specify the parameters.
Dave Longley: I think the right way to mark it up is to do overloading. [scribe assist by Manu Sporny]
Gregg Kellogg: That sounds reasonable to me. [scribe assist by Manu Sporny]
PROPOSAL: Express the WebIDL for functions with optional parameters using the method overloading WebIDL pattern.
Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
Markus Lanthaler: +1
RESOLUTION: Express the WebIDL for functions with optional parameters using the method overloading WebIDL pattern.
Markus Lanthaler: when will the javascript implementation will be ready?
Dave Longley: should take 10 minutes? Should be rather straightforward (not all is fixable in JS though)

Topic: ISSUE-223: JsonLdOptions base vs. @base

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/223
Manu Sporny: We were going to talk about this on the issue tracker, nobody seems to have had time to do it. [scribe assist by Manu Sporny]
Markus Lanthaler: I disallowed @base to take relative IRIs as value
Manu Sporny: Do we have issue markers for this in the spec
Markus Lanthaler: Yes, we do

Topic: Compaction corner cases

Dave Longley: https://github.com/json-ld/json-ld.org/commit/ddca14bcff5e28491ac1eb0c16414dfc3a5270f2
Manu Sporny: PROPOSAL 1: If the result of compaction is an array at the top level, always wrap it in @graph (default graph). This means that the result of compaction will always be an object.
Manu Sporny: PROPOSAL 2: If the result of compaction is an array at the top level, only wrap it in @graph (default graph) if a context has been passed. This means that if compaction was called without passing a context (or a null context), the result might be an array or an object, depending on the number of nodes at the top level.
Dave Longley: the question is: if you compact an array, will the result always be an object or just if a context has been passed
Gregg Kellogg: I think avoiding @graph when possible might be a good thing
Markus Lanthaler: You don't always get an object back. [scribe assist by Manu Sporny]
Markus Lanthaler: Do we really allow passing 'null' for the context parameter in the compaction call? [scribe assist by Manu Sporny]
Markus Lanthaler: We use the same thing in flatten [scribe assist by Manu Sporny]
Markus Lanthaler: The flattening result is in expanded form, would it be simpler to say that you can't pass 'null' for a context. [scribe assist by Manu Sporny]
Dave Longley: I wonder if people would prefer to pass an empty context. [scribe assist by Manu Sporny]
Markus Lanthaler: the other problem is that if we pass null for context to flatten the result will be in expanded form
Dave Longley: I think empty contexts are already a corner case.. but if they use it with arrays they might wanna just get back arrays
Markus Lanthaler: Typically, JSON developers want an object at the top level and not an array. I know @graph isn't the simplest feature we have, but at least it's consistent. [scribe assist by Manu Sporny]
Markus Lanthaler: That's regardless of what kind of context you pass. [scribe assist by Manu Sporny]
Manu Sporny: I prefer PROPOSAL 1 [scribe assist by Manu Sporny]
Markus Lanthaler: me too [scribe assist by Manu Sporny]
Dave Longley: I don't feel too strongly about it, it's a corner case, it would simplify the code. [scribe assist by Manu Sporny]
Gregg Kellogg: I don't feel strongly about it
Gregg Kellogg: I don't feel strongly about it. [scribe assist by Manu Sporny]
Dave Longley: I'm just a bit concerned if this turns out to become a popular feature (using empty contexts with arrays)
PROPOSAL: If the result of compaction is an array at the top level, always wrap it in @graph (default graph). This means that the result of compaction will always be an object.
Manu Sporny: +0.8
Gregg Kellogg: +0
Markus Lanthaler: +1
Dave Longley: +0.3
Paul Kuykendall: +0
RESOLUTION: If the result of compaction is an array at the top level, always wrap it in @graph (default graph). This means that the result of compaction will always be an object.
Markus Lanthaler: We need to get a resolution down for null being passed as a context to .compact() [scribe assist by Manu Sporny]
PROPOSAL: When a context is passed into the .compact() function call, it MUST NOT be the 'null' value. If a null value is detected, an error must be thrown.
Markus Lanthaler: +1
Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
David I. Lehn: +0
RESOLUTION: When a context is passed into the .compact() function call, it MUST NOT be the 'null' value. If a null value is detected, an error must be thrown.

Topic: ISSUE-229: Test Suite

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/229
Manu Sporny: Gregg did quite some work on it already
Gregg Kellogg: http://json-ld.org/test-suite/reports/
Gregg Kellogg: I made changes to the test suite to allow it to be used as a normal RDF-style suite
... EARL reports are then automatically converted to HTML reports
Dave Longley: maybe use @type: @vocab for the manifest types
... markus requested test numbers to be included which is simply enough to do
Gregg Kellogg: http://json-ld.org/test-suite/
Dave Longley: jld:PositiveEvaluationTest - PositiveEvaluationTest (via {"@id": "jld:PositiveEvaluationTest", "@type": "@vocab"})
... secondly I did a simple jQuery + Mustache plugin to list the tests in the manifest
... we can improve the output by CSS and adding stuff to the manifest
Gregg Kellogg: http://www.w3.org/2011/rdf-wg/wiki/Turtle_Test_Suite
... we need to be sure to describe everything a developer needs to run the tests
... Turtle does this using a wiki page
... we don't have any syntax tests
... we have 2 or 3 classes of tests
Manu Sporny: we need to tell people how to run it etc. do you think we have most stuff in place?
Gregg Kellogg: the base should be consistent with where the tests are living in the long place
... sandro also suggested to add an "approved test" class
... I had to add a hash-URI to each test so that someone can reference it
... I don't know if we have enough information in the test-suite index.html to run the tests
Manu Sporny: the tests return a 404
Markus Lanthaler: the "tests" subdirectory is missing
Gregg Kellogg: we could do some ajax stuff to display the test
Dave Longley: we should use the @type: @vocab feature for marking up the test type
Markus Lanthaler: What do we do with error tests and tests of the API flags? Variations of the existing tests. [scribe assist by Manu Sporny]
Gregg Kellogg: We need a generic way of saying: "When something is run, expect an error" [scribe assist by Manu Sporny]
Gregg Kellogg: We may want to specify the type of detail we expect in the error. [scribe assist by Manu Sporny]
Gregg Kellogg: I saw an error test where the result was a string
Dave Longley: use some kind of "exception" property
Dave Longley: rather than "result"
... we should probably use a separate property for that
... using different options could either be done with a single property serializing all options or a property for each option
... nevertheless we should separate API tests from algorithm tests
Manu Sporny: I think most APIs are tested in-browser
... what we have is mostly for libraries not browsers
... we need kind of a endpoint to invoke the tests
Paul Kuykendall: we are only implementing very small portions of the API at the moment
... we've implemented expand and will be working on compact
... on the client side everything will be turned in to RDF triples anyway
... we use it just as a simple serialization format
Markus Lanthaler: "@type": ["jld:PositiveEvaluationTest", "jld:CompactTest"]
Gregg Kellogg: I will change it to "@type": [ "PositiveEvaluationTest", "CompactTest" ],
... this vocabulary is not defined anywhere
... we will probably define the vocabulary in the test description file
Manu Sporny: There are a lot of things to discuss regarding the test suite
... but maybe not today.. perhaps we should open a few issues against the test suite
... and discuss it next week