W3C home > Mailing lists > Public > public-linked-json@w3.org > April 2013

JSON-LD Telecon Minutes for 2013-04-09

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 09 Apr 2013 12:06:29 -0400
Message-ID: <51643C85.4010201@digitalbazaar.com>
To: Linked JSON <public-linked-json@w3.org>
CC: RDF WG <public-rdf-wg@w3.org>
Thanks to Markus for scribing! The minutes from today's telecon
are now available.

http://json-ld.org/minutes/2013-04-09/

Full text of the discussion follows including a link to the audio
transcript:

--------------------
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:
   http://json-ld.org/minutes/2013-04-09/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

-- 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, 9 April 2013 16:06:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:37 UTC