Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
WebIDL dependency #238
So we're in the odd situation with JSON-LD-API of needing a normative reference to WebIDL, which might stay stuck in CR for some time. In this case, however, we can proceed to REC, even with it in CR, by following these instructions:
You'll need to provide evidence that the WebIDL used in your spec is stable, as follows:
I don't actually understand this at all. I'm hoping some other people do. If not, I'll work harder to figure it out.
Unfortunately it fails with the following errors:
I've had a look at the idlharness repo. There was only a issue for dictionaries (w3c/testharness.js#18) so I've opened two new issues:
I've also discovered a bug (?)in ReSpec for which I filed an issue as well: https://github.com/darobin/respec/issues/182
@darobin, till when do you think those issue could be resolved? Could you please also have a quick look at the idlharness I created to make sure it's correct.
Thanks a lot,
_Robin Berjon's reply:_
On 02/04/2013 12:48 , Markus Lanthaler wrote:
That's not the problem you're seeing. The above output to the console is from warnings, not errors. What they mean is that idlharness will not test those constructs, but they don't prevent all the other tests to run.
The problem you have is that you haven't loaded testharness.js, and so you're getting ReferenceErrors:
The reason for that is that your HTML is broken:
If you fix that you should be able to get a clean run from idlharness.
Have you tried this with the canonical ReSpec instead of your local copy? I fixed a number of bugs with union type formatting a little while back. It's possible that some are still there, but I'd rather know with the real thing (local copies are evil).
I don't have an ETA but updates to idlharness are being planned. In the meantime, what you should do is this:
That should be enough to get out of CR (at least, it's a case I would make).
referenced this issue
Apr 2, 2013
Anyway, jsonld.js gets a 8/14 on the idltest now.
I don't know either.. will ask Robin.
Since options is optional, you have to remove it.. so
jsonld.expand = function(input, options, callback)
jsonld.expand = function(input, callback)
and you retrieve the options from the arguments array. If you change this, we pass 11 of the 14 tests.
That's true.. but not if one parameter is required and the other is optional. Otherwise you can't omit the options parameter. You have to always pass either an empty object or null. I think we should leave it as it is in the current spec.
I thought that wouldn't work because I was reading the '?' in the syntax as meaning optional -- so I thought the parameter count was just incorrect. I see the word 'optional' there now and assume that's the syntax that indicates whether or not something is actually optional. I can make the WebIDL API pass those other 3 tests when I get a chance now.
You don't have to do that, you can still just omit the extra property. The function can use type checking to determine what the parameters are (this is how it's done in JS/node.js -- and the callback is always last regardless of various optional params). I'd prefer it to be last as it goes against convention otherwise (at least in JS/node.js).
Yeah, you could do that (manually) but it's prohibited by the WebIDL spec unless I misread it:
An argument is considered to be an optional argument if it is declared with the optional keyword. The final argument of a variadic operation is also considered to be an optional argument. Declaring an argument to be optional indicates that the argument value can be omitted when the operation is invoked. An argument MUST NOT be declared to be optional unless all subsequent arguments to the operation are also optional.
To make the WebIDL a bit easier to read I would propose to add two typedefs:
typedef (object or object or DOMString) JsonLdInput;
This doesn't change anything but makes the WebIDL much easier to read.
added a commit
Apr 5, 2013
That's very unfortunate. We could declare the callback optional and throw an error if it isn't provided, but it is hacky. I'm not sure if that's better or worse than breaking convention; it will be surprising either way, it's just a question of which way will generate more surprises. I think my vote would be to avoid breaking convention.
A way around this, would be to use method overloading. Unfortunately that doesn’t seem to work either as dictionaries and callbacks are “not distinguishable”.
I discussed this problem with Robin Berjon. According to him, that’s a bug in WebIDL (that he filed after our discussion: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21640). He recommends to use Futures instead of callbacks:
That would mean, however, that we would introduce a normative dependency on DOM - which I think, we don't wanna do at this stage.