The spec should discourage people from extending the manifest format.

[marcoscaceres]

The spec currently encourages extending the manifest format. Given that JSON does not support any mechanism for distributed extensibility (not even crappy namespaces), I think extensions to the manifest format need to be strongly discouraged (or standardised if really needed).

[mounirlamouri]

What about 'orientation' or 'activities'/'intent', etc?

[marcoscaceres]

@mounirlamouri sorry, I don't understand your question? Are you saying that orientation and stuff related to activities would appear in the manifest format? If so, we would need to standardise a means for adding those as appropriate. The use case for Initial orientation makes perfect sense to me.

As an aside, it would also be great if we could make orientation work with The Screen Orientation API. I don't know yet what I mean by "work with", but something to think about.

[mounirlamouri]

My idea is thot Screen Orientation API will simply plug an 'orientation' property to the manifest format. We should indeed find a way to prevent name collisions though.

[marcoscaceres]

That's fine. The purpose of the text I am proposing is to try to reduce proprietary extensions and authors adding random things that could cause compatibility problems in the future. But new specs that extend the set of properties are certainly welcomed (as long as they are done through the W3C). If that is not clear in the text I have proposed, then I need to update it.

[mounirlamouri]

I understand what you tried to do but I think it should be clearer that this text is actually targeting authors. My text was targeting implementers. Maybe it would be good to have a text for each of them?

[marcoscaceres]

Yes, making the distinction between authoring requirements and user agent requirements would be good.

I'll note that there is a small problem overall with the spec in that it lacks a conformance section that identifies the product to which the conformance requirement applies. As a consequence, there is lots of places where MUST/SHOULD/MAY is being used inappropriately. I'll add a bug for that.

[marcoscaceres]

Ok, created bug for the comment above.

I'll also update the text for this pull request and ping you once that's done.

[marcoscaceres]

Ok, I've updated the PR based on the feedback. Let me know if the new text is better.

[marcoscaceres]

Fixed merge conflicts. Can be merged again if it's ok.

[mounirlamouri]

We should add a property for authors to stick stuff in.

[marcoscaceres]

Proposal for "data":

The data member represents any additional data that the developer might want to provide for their application. The value is any valid JSON data structure or type.

[marcoscaceres]

I'll add an example in section that defines "the data member", but that will be in a separate PR.

[mounirlamouri]

This PR has merging issues. By that I mean that it has ======, HEAD and other stuff in the content.

Also, I've been discussing with Fabrice (who worked on OWA for Mozilla) and he said that maybe we could simply not expose any other attribute than the ones that are defined in the specification. I believe that could be enough for the moment and we could expose a 'data' attribute later if needed. What would you think about that?

[marcoscaceres]

Fixed the "=====" silliness - sorry about that.

Regarding exposing only spec-defined attributes... it doesn't really address the problem and introduces at least one new one. The main problem that we have is:

• Author or vendor specific extensions to the existing members risk compatibility clashes with future versions of the specification.

For example:

{
  "developer": {
   ... 
   "support": "support@bar.com",
   "support_href": "http://bar.com/game/support"
 }
}

In the above, the vendor specific extensions ("support" and "support_href") would only apply to some vendor. If the WG wanted to then make "support" a URL, we would clash with existing content. I don't see a way to stop this from happening or how to manage it in the wild (apart from the guidance given in the spec, which may or may not help). These kinds of extensions are primarily relevant to implementors.

About exposing only spec-defined attributes: Unknown values are already ignored by the parsing algorithm (good for backwards compat), but it's not harmful to give developers full access to the manifest (i.e., we should not trim the JSON when exposing it to developers). Trimming the JSON has a function in that it can provide authors with the ability to polyfill missing features (by checking things in the manifest and if they appeared in the app). This is good for backwards compatibility and can be used to progressively enhance an application.

For example, if the application knows that it's on a legacy user agent that does not handle the "support" member, it may use find an alternative means of displaying the support information (i.e., through a custom UI in HTML).

Lastly, I think we should expose the data attribute. If one thing is for sure, it's that authors will find ways of extending the manifest with stuff they need. Even if we were to trim the unknown attributes, devs could still XHR the manifest from within the package and JSON.parse() it - so, again, trimming the JSON won't help and will just cause developers to do a little more gymnastics (or someone will build a library to XHR the manifest, and then mix-in the missing stuff onto the application.manifest attribute exposed to the app).

[draggett]

On 15/04/13 10:33, Marcos Caceres wrote:

Lastly, I think we should expose the data attribute.

Just for clarification. By "data attribute" are you suggesting something similar to the HTML specification, i.e. for manifest properties starting with the "data-" prefix, the meaning of the property will be specific to this application, and interpreted by the application's scripts?

Dave Raggett dsr@w3.org http://www.w3.org/People/Raggett

[marcoscaceres]

@draggett, no. The current proposal is to have a single "data" attribute at the root of the manifest.

{
  ...
  "data": {"myCustomStuff": [1,2,3]}
}

Still not sure if prefixing vendor/custom properties is a good idea or not... like (naming aside):

{
  "developer": {
   ... 
   "data-support": "support@bar.com",
   "data-support_href": "http://bar.com/game/support"
 }
}

What would be the motivation for devs or vendors to do that? or conversely, the punishment for not doing it? As I mentioned before, if this is painful for those involved, they will likely find ways around it.

[mounirlamouri]

We had an offline discussion with Marcos regarding this and we realised that there are other options than proposing to extend the manifest at a particular place:

• filtering anything that isn't known by the runtime. The advantage is that it can help the application to know if a particular feature was taken into account and then emulate it but it might create issues with implementations adding new properties that would be shown and thus will have to be implemented by every one.
• not showing the manifest at all. The advantage is that all problems are resolved but some applications would need information inside the manifest like the app title, icon and description. Typically a marketplace or a homescreen. But those applications would also prefer to have a manifest object that already has localized strings so we could also imagine some kind of processed manifest.

[marcoscaceres]

Right, another option is to figure out what the common things that Dev's need from the manifest are and just expose those on the application object. Like:

application.name - the localized application name.

[marcoscaceres]

Moved to: https://github.com/sysapps/manifest/issues/12