Respec: Do not signal missing definitions for methods marked with [Default]

[dontcallmedom]

The name extended attribute Default defined in WebIDL allows to define the toJSON method as having the default behavior; in that case, I think it would make more sense if ReSpec didn't warn about it if there is no in-line definition (and possibly, instead directly link to the default definition given in the WebIDL spec)

[marcoscaceres]

@dontcallmedom I'm probably totally wrong here, so please correct me, but the problem I see is that "Default" can mean different things depending on what the extended attribute is applied to.

We could make ReSpec smarter, however, whereby if it sees "Default" and "toJSON" then it links to the "#default-tojson-operation".

[marcoscaceres]

Actually, my suggestion above wouldn't be good. I think spec authors should have to explicitly define toJSON() as:

When <dfn>toJSON</dfn> is called, run [[!WEBIDL]]'s 
<a data-cite="WEBIDL#default-tojson-operation">default toJSON operation</a>.

I know it's a bit more work - but otherwise just linking to "Default" doesn't help the reader so much, because they then need to go and figure out what the default for toJSON() is. Not defining toJSON() would also make specs inconsistent, because ReSpec forces you to define all operations properly, and so toJSON() would be missing (yes, I know it's self documenting because of the name).

@tobie, would value your opinion on the above also? Am I being overly annoying to spec authors in forcing them to define toJSON()?

[tobie]

So we don't really have plans right now to use [Default] beyond toJSON.

I'd encourage you to link it directly and I'll let you know if we ever extend it.

[marcoscaceres]

Ok, so tasks here:

• [x] filter out toJSON() from wanting to link.
• [x] replace current Default link location with #default-tojson-operation.

Will try to get to it soon.

[marcoscaceres]

Ok, I did one better... now automatically links toJSON() and [Default] ... and also allows Editors to define toJSON(), if they wish for it to be included in the ToC ... like we do for Payment Request.

[marcoscaceres]

fixed typo above.

[dontcallmedom]

@marcoscaceres it looks like this still emits warnings on toJSON() having no <dfn>:
No <dfn> for operation toJSON in RTCSessionDescription.

[marcoscaceres]

@dontcallmedom, sorry, could you please link to the spec also? It's probably just not correctly defined.

[marcoscaceres]

It should still hopefully be defined as, for example:
https://github.com/w3c/payment-request/blob/gh-pages/index.html#L1889-L1897

[marcoscaceres]

Oh, hehe... I have the memory of a gold fish. I said you could do it without defining it.

[marcoscaceres]

NB: worst... it turns out gold fish have really good memory.

[marcoscaceres]

Closing this, as I think current practice across specs is good and clear.

[saschanaz]

So we actually already have a fallback behavior, still with a warning. IMO one should be able to directly link to the IDL spec without any type of warning, especially when the operation is explicitly marked as [Default].

My suggested behavior:

1. If a dfn is found, link it and terminate
2. If we have [Default], get a default link for the operation identifier. ThrowWarn only if not found.

@marcoscaceres, what do you think?

[marcoscaceres]

Yes, that sounds good.