Add Options Extensibility section #435
Conversation
jrhender
requested review from
msporny,
mavarley and
mkhraisha
as code owners
Improvement suggestions from Ted and Dave in PR feedback Co-authored-by: Dave Longley <dlongley@digitalbazaar.com> Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
index.html
Outdated
| Property keys can be any string but they should be appropriately namespaced (for example by using URIs) | ||
| in order to avoid collisions with extensions in other implementations. |
There was a problem hiding this comment.
I don't know if we need to provide this advice or if it should be adjusted somewhat. We might want to discuss this bit on the next call.
It seems the danger here would actually be with a conflict with something that gets standardized, not with different implementations. This is because if a different implementation were to be swapped in, you'd certainly first stop using any previous-implementation-specific options, regardless of their names. You'd then add any new-implementation-specific options (and it then wouldn't matter whether the same names were used or not). In no case would you be using both implementations at once (or not know which one you were talking to).
If this argumentation is correct and the danger is with conflicting with a future standard option, we might want to follow the "Don't use X- or webkit- prefixes" advice given for experimental HTTP headers and CSS properties, i.e., don't recommend any special name scoping / qualifiers here.
There was a problem hiding this comment.
Until @dlongley's concern above is addressed, this text should be refined a bit, a la --
| Property keys can be any string but they should be appropriately namespaced (for example by using URIs) | |
| in order to avoid collisions with extensions in other implementations. | |
| Property keys can be any string, but they should be appropriately namespaced (by using URIs, for example) | |
| to avoid collisions with other extensions. |
There was a problem hiding this comment.
Yeah, I hesitate at saying that the extensibility mechanism is to use full URIs as well. Feels like just text strings could work fine here, and perhaps a registry? (though I shudder at the need for a registry)
There was a problem hiding this comment.
(also, I left a should in there, but if it remains, it should be changed to SHOULD or ought to)
There was a problem hiding this comment.
| Property keys can be any string but they should be appropriately namespaced (for example by using URIs) | |
| in order to avoid collisions with extensions in other implementations. | |
| Property keys can be any string, but they SHOULD be appropriately namespaced (by using URIs, for example) | |
| to avoid collisions with other extensions. |
| Property keys can be any string but they should be appropriately namespaced (for example by using URIs) | |
| in order to avoid collisions with extensions in other implementations. | |
| Property keys can be any string but they should be appropriately namespaced (for example by using URIs) | |
| in order to avoid collisions with extensions in other implementations. |
There was a problem hiding this comment.
or
| Property keys can be any string but they should be appropriately namespaced (for example by using URIs) | |
| in order to avoid collisions with extensions in other implementations. | |
| Property keys can be any string but they ought to be appropriately namespaced (for example by using URIs) | |
| in order to avoid collisions with extensions in other implementations. |
Adds a new "Options Extensiblity" sub section with the information discussed here: #335 (comment)
Preview | Diff