-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove reserved concept of refreshService
from the spec
#1113
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR should also include a mention in the Revision History section about the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, we can retain the section and remove
refreshService
from the "reserved properties" table.
Yeah, we're in a weird place w/ the "legacy but reserved properties". There are a few options here:
- Mark them as at risk (in the section they're about), and to be removed by the end of CR, if there are not at least two implementations for a single type. Don't add them to the reserved properties table.
- Do item 1 above, AND add them to the reserved properties table and say that the property will remain in the reserved properties table if there are not at least two implementations for a single type. If we do this, we just end up deleting either the section, or the entry in the reserved properties table. That is, we just remove text instead of having to shift text (which sometimes raises eyebrows during CR (and then you have to explain why you're not trying to pull something over on the W3C, that this was an intentional addition to the spec).
- Do what's being done in this PR, and delete the section, and add it to the reserved properties table.
If we do item 3, we are (possibly) reducing the chances that it gets implemented because the spec doesn't say what to implement. One could argue: "Wait a second, you're expecting people to implement something that's not spec'd?" -- the counter-argument to that could be: "Well, it's spec'd in v1.1 -- do that." -- that whole exchange is a bit shaky on both sides of the exchange.
If we do item 1, then we have to add text after CR, which always requires quite a bit of explanation as to why you're making a normative change so late in the process.
If we do item 2, we just delete something that we warned people we might delete during CR. This, from a process perspective, feels the easiest to me.
Based on that, -1 to merging this PR for two reasons: 1) I'd prefer we do item 2 above (from a process perspective), and 2) I already know that there are at least two independent implementations of this feature -- TruAge, and a digital wallet vendor that can probably speak more openly about this in a couple of months.
I have attempted to demonstrate what 2 would look like in this PR: #1115
Closing the PR, I think the working group is making big mistakes by keeping stuff like this around, instead of adding it back when it is ready, git preserves history, but it only takes one reading of this section to be mislead into believing these features have interoperability. |
Now that it has been reserved, we can remove the section from the spec and close #981
Alternatively, we can retain the section and remove
refreshService
from the "reserved properties" table.Preview | Diff