- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 23 Apr 2013 09:58:41 -0400
- To: Linked JSON <public-linked-json@w3.org>
- CC: RDF WG <public-rdf-wg@w3.org>
The minutes from last week's telecon are now available. http://json-ld.org/minutes/2013-04-16/ Full text of the discussion follows including a link to the audio transcript (audio not uploaded yet, will do so later today): -------------------- JSON-LD Community Group Telecon Minutes for 2013-04-16 Agenda: http://lists.w3.org/Archives/Public/public-linked-json/2013Apr/0014.html Topics: 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. Chair: Manu Sporny Scribe: Manu Sporny Present: Manu Sporny, Markus Lanthaler, Dave Longley, Paul Kuykendall, Gregg Kellogg, Niklas Lindström Audio: http://json-ld.org/minutes/2013-04-23/audio.ogg 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: http://lists.w3.org/Archives/Public/public-rdf-comments/2013Apr/0022.html 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. Gregg Kellogg: http://www.w3.org/2011/rdf-wg/track/ 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. Gregg Kellogg: https://www.w3.org/2011/rdf-wg/track/products/11 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. Markus Lanthaler: https://www.w3.org/2011/rdf-wg/track/issues/124 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. Markus Lanthaler: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21640 Manu Sporny: Is there an example where the options are last? Markus Lanthaler: WebRTC and Geolocation are two Dave Longley: http://en.wikipedia.org/wiki/Continuation-passing_style Manu Sporny: I don't quite agree with Boris here. Markus Lanthaler: http://www.w3.org/TR/geolocation-API/#geolocation 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. Markus Lanthaler: http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCPeerConnection 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. Paul Kuykendall: http://stackoverflow.com/questions/2534436/jquery-plugin-adding-callback-functionality 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 Gregg Kellogg: https://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG 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. Markus Lanthaler: http://dom.spec.whatwg.org/#future Manu Sporny: We can't reference a spec that isn't in LC. Manu Sporny: Any volunteers? Dave Longley: http://stackoverflow.com/questions/2534436/jquery-plugin-adding-callback-functionality 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: niklas, see http://lists.w3.org/Archives/Public/public-rdf-comments/2013Apr/0022.html%29: 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? s/issue/result/ 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 Markus Lanthaler: https://github.com/json-ld/json-ld.org/commit/657c90f3fc4050fce006fa11a2a420e7e4efe049 Markus Lanthaler: https://github.com/json-ld/json-ld.org/commit/4751e057970d3ca3161cb43c37cd6f7f5c0ef57d 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: https://github.com/json-ld/json-ld.org/commit/7cd5b8006be86e3ab4c1cd6e33b4ea39a171e616 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? Markus Lanthaler: https://github.com/json-ld/json-ld.org/commit/657c90f3fc4050fce006fa11a2a420e7e4efe049#commitcomment-3020250 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 -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/
Received on Tuesday, 23 April 2013 13:59:04 UTC