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.
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.
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.
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) }
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.