Re: javascript manifests in webapps group

On 12 May 2012, at 12:55, Charles McCathieNevile wrote:

> On Sat, 12 May 2012 13:32:54 +0200, Marcos Caceres <w3c@marcosc.com> wrote:
>> On Friday, 11 May 2012 at 21:25, Scott Wilson wrote:
>>> Thanks Charles,
>>> 
>>> I've seen this format before, and it can potentially be aligned with Widgets, e.g.
>> I would be keen to see them align. They are basically the same.
>>> 1. Rename properties to match their direct equivalents in Widgets P&C (e.g. developer -> author, screen_size:min_width -> width etc)
> 
> Hmm. To go from one to the other you already need a translation, so I don't think a difference in the names is critical. Developers will make mistakes, but there is also a question of whether we're better with the XML names, or the JSON names - and maybe we should start with the two different ones then pave the cowpaths that get accidentally trodden.
> 
> (Dublin Core has an issue like this. They have a property Creator, and no Property Author. But any system that wants to work with dublin core found in the wild has to handle the "oficially non-existent" dc:author because it is often used by developers. It turns out not to be a huge hassle in the medium term, just a minor annoyance and a reminder why we do standards in the first place).

I don't think it would be a huge bother to change the JSON to use the same names as TWI. Effectively the manifest part is equivalent to turning TWI into JSON (much easier than P&C as TWI is already a JS spec).

>>> 2. Feature names should be IRIs as in WIdgets rather than strings
>> 
>> I think we made a boo-boo in widgets by using URIs for feature names.
> 
> Not sure. They are common still in some patterns, and have some noted advantages. Maybe we'd be better to leave the dereferenceable URIs in public for XML P&C, and include in the translation to JSON a simplification from URI to plain words.
> 
>> This should just be an opaque string (URIs that can be dereferenced s suck as identifiers).
> 
> That said, the design pattern I have been using at opera is to mint opera:feature URIs. Which is a dirty hack - neither dereferenceable, nor a beautiful word. It just mewts validation requirements

Here are some of the ones we minted for existing libraries and specs implemented for widgets:

http://jquerymobile.com
http://openajax.org/hub
http://oauth.net/2

>>> 3. Orientation and fullscreen needs harmonizing with viewmodes
>> 
>> Viewmodes doesn't really handle orientation, it should be handled by the device adaption CSS spec:
>> http://dev.w3.org/csswg/css-device-adapt/#the-lsquoorientationrsquo-descriptor
>> 
>> 
>>> 4. Add any missing properties defined in P&C and TWI such as license, short_name
>> 
>> agreed.
>>> I think also the app store registry, lifecycle and events would be better split out from the JSON manifest spec.
> 
> Yeah, I don't see that "which spec things are in" is a particularly crucial question, and anyone prepared to die on that hill is focused on the wrong things. The events seem to make more sense as part of an update to the Widget Interface - and in any case would be good for both JSON and XML packaged apps, IMHO.

Right, there are parts of this proposal that are like a JSON serialization of TWI (great!), there are parts that could be added methods and events in TWI (great!) and parts that are kind of an app store system and security model (need to think about more carefully, but could be great too!)

> 
>>> All doable I think if Mozilla are happy to be flexible on this.
>> 
>> I imagine/hope they would be, otherwise it's pointless to push for standardisation if only one company backs the format (that's just standardisation for marketing reasons).
> 
> Right.
> 
> cheers
> 
> -- 
> Charles 'chaals' McCathieNevile  Opera Software, Standards Group
>    je parle français -- hablo español -- jeg kan noen norsk
> http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Saturday, 12 May 2012 15:15:36 UTC