JSON-LD Community Group Telecon

Minutes for 2013-04-16

  1. Last Call Issues
  2. Last Call Issue: Order of parameters (options or callback last) - by Boris Zbarsky
  3. JSON-LD Specification Bugs
  4. Test Suite Design
Action Items
  1. Markus to contact public-script-coord@w3.org asking for review of JSON-LD API.
  2. Manu to ping WHATWG on the issue of where the callback parameter should go. Ask the TAG if the WHATWG doesn't have a strong opinion.
Manu Sporny
Manu Sporny
Manu Sporny, Markus Lanthaler, Dave Longley, Paul Kuykendall, Gregg Kellogg, Niklas Lindström
Audio Log
Manu Sporny is scribing.
Manu Sporny: Any updates/changes to the agenda?
Markus Lanthaler: Do we want to discuss the comment from Boris about the API?
Markus Lanthaler: here's the link
Markus Lanthaler: and the issue I created: https://github.com/json-ld/json-ld.org/issues/240

Topic: Last Call Issues

Manu Sporny: We're going to want to track all issues using the W3C RDF WG issue tracker.
Manu Sporny: We should have something called JSON-LD Last Call 1
Markus Lanthaler: Does it pick up comments in public-rdf-comments ?
Manu Sporny: It should if it doesn't already.
Markus Lanthaler: It would be nice to track in github.
Manu Sporny: yes, but it doesn't track e-mails to the mailing list.
Manu Sporny: We probably want to discuss this with RDF WG, seeing if it would be ok for us to handle these issues in an official capacity in this group.

Topic: Last Call Issue: Order of parameters (options or callback last) - by Boris Zbarsky

Markus Lanthaler: The issue is rather simple, stylistic issue. The callback parameter is usually the last item.
Markus Lanthaler: Boris is saying that the options parameter should come last.
Markus Lanthaler: A couple of people are trying to push futures for such things, that was part of the discussion we had with the WebIDL bug we filed. There are 2-3 people that said we should do it with futures instead.
Manu Sporny: Is there an example where the options are last?
Markus Lanthaler: WebRTC and Geolocation are two
Manu Sporny: I don't quite agree with Boris here.
Dave Longley: If you're using continuation passing style, typically control is passed using the last parameter. I don't know what Web APIs he's talking about that do what he's saying. I'm unaware of APIs that have the options parameter after the callback. After doing some research, I couldn't find any that did that.
Dave Longley: It is very consistent to have the callback as last. There are a number of libraries that assume the callback as the last parameter.
Manu Sporny: Doesn't it mess the async library up in browsers/node.js if you don't have the callback parameter as the last parameter?
Dave Longley: I think it would be unusual to pass options last.
Paul Kuykendall: Doing some random google searches on this, even jquery and other popular libraries, most of the functions have the callback as the last parameter.
Manu Sporny: How about we find a good set of APIs as examples and see what they do.
Dave Longley: It's well established in Node.js that the callback is the last parameter. We need to find Web APIs that pass option as the last callback.
Markus Lanthaler: Yes, we should find examples.
Markus Lanthaler: The group that is standardizing JavaScript has asked for closer coordination with W3C. We should ask them to review the JSON-LD API.
Manu Sporny: Agreed, please do that Markus.
Markus Lanthaler: public-script-coord@w3.org
ACTION: Markus to contact public-script-coord@w3.org asking for review of JSON-LD API.
Dave Longley: It's going to be unfortunate if everything that uses WebIDL goes against what most developers are doing out in the wild.
Gregg Kellogg: Ruby allows you to callback as last parameter as a block, so easy to do.
Dave Longley: WebIDL probably does it this way to support languages like C++ and Java.
Dave Longley: If we don't have this as the last parameter, we may want to just go with futures instead of going w/ something that's unconventional.
Manu Sporny: We can't reference a spec that isn't in LC.
Manu Sporny: Any volunteers?
Paul Kuykendall: One of our developers said callback before options.
Dave Longley: We need to be clear about what we're looking for. If the WebIDL spec calls for options after callbacks, it's a mistake.
Markus Lanthaler: Well, we need to figure out which direction we're going.
Gregg Kellogg: Maybe we should ask the TAG?
Gregg Kellogg: Anne, Yehuda, etc. Feedback from them would be good.
ACTION: Manu to ping WHATWG on the issue of where the callback parameter should go. Ask the TAG if the WHATWG doesn't have a strong opinion.
Markus Lanthaler: of course without the %29; at the end
Niklas Lindström: What about futures? We don't have the time to do anything with that. Could that influence our position in any way? Futures are returned as a callback? Could that influence the decision?
Niklas Lindström: If the callback was omitted, you should have the results returned, maybe? I don't know where Node.js / Web APIs stand on this.
Markus Lanthaler: futures are returned as return value, not as a callback
Dave Longley: Maybe we could say that the callback is optional as well, and it returns the issue synchronously?
Niklas Lindström: Maybe we can return a proto-future - it's not a DOM4 future, then we're not bound by that.

Topic: JSON-LD Specification Bugs

Dave Longley: Effectively, we've realized that there is a situation where if you have a @context and you want to define a term to point to itself, we want to figure out what the processor should do.
Dave Longley: Look at the examples above.
Dave Longley: The first example uses rdfs: which is fine.
Dave Longley: The second example uses 'term' and removes previous definition of the term immediately. That's what I think should happen.
Dave Longley: If you look at the 3rd link, in that case @vocab is messed up if we don't reset the 'term' if it is redefined.
Dave Longley: If you re-use anything on the left hand side on the definition in the right-hand side, you should define it somewhere in the local context.
Dave Longley: Markus thinks that you could use something that's previously defined.
Dave Longley: When you start defining a term, that immediately removes any previously defined definition. It's a simple and consistent rule.
Dave Longley: Markus think that if you can re-use it, do that. That decision results in two different outputs.
Manu Sporny: What does the spec say right now?
Dave Longley: It's ambiguous.
Gregg Kellogg: We do have checks for circular dependencies, right?
Dave Longley: Yes, but is this a circular dependency?
Niklas Lindström: I'm a +1 on "when a term is defined, remove it (set it to null?) if it already exists"
Markus Lanthaler: Dave's approach doesn't seem very consistent to me.
Dave Longley: It doesn't seem strange to me to do that.
Niklas Lindström: .. i.e. before interpreting the RHS
Manu Sporny: I'm a +1 on completely removing a definition of a term when it's defined as well (agree with niklasl, and dlongley)
Markus Lanthaler: You still overwrite the entire definition when you're done using my approach.
Niklas Lindström: .. I'd find that consistent with the "no partial redefinition" design
Dave Longley: if you have: "term": {"@id": "v:foo", "@type": "v:bar"} and then you add another context with "term": "term" ... does it keep @type? will authors understand that?
Dave Longley: I'm concerned that a partial re-definition might confuse web authors.
Markus Lanthaler: It's not a partial re-definition, I don't think.
Markus Lanthaler: "term": {"@id" : "term", "@type": "@id" }
Dave Longley: Isn't what you're doing at that point kinda doing a partial re-definition? Addend your definition? If we introduce that concept couldn't it be confusing?
Markus Lanthaler: It's confusing sometimes, but it's not confusing at other times.
Paul Kuykendall: FYI: Timebox has been exceeded
Markus Lanthaler: "otherTerm": "term"
Niklas Lindström: .. never allow partial redefinition! :)

Topic: Test Suite Design

Manu Sporny: Any changes that need to be made to the test suite?
Gregg Kellogg: We have a rough design so far. Do we need to have different classes of tests?
Gregg Kellogg: The value range of the properties we're using - what do we expect? Typically it's a URL where there is a fine to look at? We do have cases where it's a string value - an exception text string. We shouldn't have the same property used for two totally different types of data.
Gregg Kellogg: In terms of a basic description, using the manifest definition, it works - been doing that all along. Reporting against that is fairly straightforward.
Gregg Kellogg: Either we're describing algorithmic behavior, if there are options to the algorithms, how do you specify that?
Manu Sporny: This is the same problem that we had in the RDFa 1.1 test suite?
Gregg Kellogg: Yes, more or less. This is more complicated because some of these parameters are not scalar parameters.
Gregg Kellogg: There is also the whole behavior of the callback.
Markus Lanthaler: compact(..., function(err, result) { if(err) then test.failed else if (result == expected) then test.success) }
Niklas Lindström: .. {"@context": {"@options": {…}} ;]
Manu Sporny: If we were doing this in Javascript, we'd just implement a mocha test suite.
Gregg Kellogg: Maybe we just want to test on an algorithmic basis - just test input and output.
Markus Lanthaler: We could expand the IDL harness, or create a JavaScript test suite.
Manu Sporny: Yes, let's do that - upload our PHP, Ruby, and JavaScript test harnesses and tell people in other languages to match that sort of behavior.
Paul Kuykendall: Yeah, that's what we did for our C# implementation.
Gregg Kellogg: Yeah, I think that's what's easiest for developers.
Niklas Lindström: .. re. Futures, for reference: here is the CommonJS Promises proposal: http://wiki.commonjs.org/wiki/Promises/A