JSON-LD Telecon Minutes for 2013-04-16

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