Proprietary extensions #2

Open
tobie opened this Issue Apr 3, 2012 · 3 comments

Projects

None yet

3 participants

@tobie
tobie commented Apr 3, 2012

The Widget Config allows for proprietary extensions through XML namespacing. We need something similar.

@richtr
richtr commented Apr 11, 2012

This is a tricky subject IMO. We could mandate that all proprietary extensions start with 'x' (LOWER CASE X) e.g. 'xPhoneNumber'. But then developers for the most part will simply ignore this and just put their own name e.g. 'phoneNumber'.

The second option, and my preferred approach right now would be to let anything go and fit our own as-yet-unknown-but-awesome-future properties around 'reserved' words used in the core spec and in use in known common extensions to the dictionary.

The priority should be on promoting developers to document their proprietary extension properties in the public domain e.g. via a web page or by pinging the group that will ultimately maintain the manifest properties dictionary.

@anantn
Contributor
anantn commented May 7, 2012

I think having the spec specify that the UA may ignore all properties not explicitly mentioned in the document would be sufficient to achieve this? I'm a little wary of adding namespacing to JSON.

@tobie
tobie commented May 7, 2012

I guess that works for a V1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment