Or you could perhaps use XML. A bit like, er, this: http://www.w3.org/TR/widgets/
On 18 Jul 2013, at 14:57, Kornel Lesiński wrote: > > I'd like to propose using HTML as basis of manifest format, similar in spirit > to Web Components imports, e.g. > > <link rel="manifest import" href="/my-app-definition.html"> > > and then my-app-definition.html could contain <link>, <meta> or other > elements. > > > Rationale: > > * while JSON is wonderful for automatic serialization, it's an annoying > format when maintained by hand (and manifest seems static and simple enough > to be maintained by hand). > > - JSON syntax is pedantic about trailing comma. Authors have to be careful > when adding new element to end of a list. > > - JSON does not support comments. Manifest is a central place of an > application, so may end up being modified by many team members, and it's > useful to comment why certain properties are the way they are, warn which > changes will cause breakage (again…), etc. > > * We already have <link rel=icon sizes>, <meta name="description">, <meta > name="application-name"> that can be reused. Authors already know these and > it may be easier to define and understand how <meta> and manifest properties > interact. > > * We already have lang & hreflang attributes, so there's no need to invent > locales dictionaries. > > * It can be inlined naturally, saving a RTT. > > * It can be mixed with Web Components allowing applications to define > everything in one place if they wish to. > > * Simple websites can reuse homepage as their manifest file: <link > rel=manifest href=/> > > > > Here's HTMLized example from the spec: > http://www.w3.org/2012/sysapps/manifest/#example-manifest > > <html lang="en" manifest="/cache.manifest"> > <meta name="name" content="The Example App"> > <meta name="description" content="Exciting Open Web development action!"> > <meta lang="es" name="description" content="¡Acción abierta emocionante del > desarrollo del Web!"> > <meta name="launch-path" content="/"> > <meta name="version" content="1.0"> > <link rel="icon" sizes="16" href="/img/icon_16.png"> > <link rel="icon" sizes="48" href="/img/icon_48.png"> > <link rel="icon" sizes="128" href="/img/icon_128.png"> > <meta name="author" content="Foo Corp."> > <link rel="author" href="http://example.org/dev"> > <link rel="author" hreflang="es" href="https://example.org/dev/es-ES"> > <style> > @viewport { > min-width: 300px; > max-width: 600px; > } > </style> > <meta name="required-features" content="touch geolocation webgl"> > <meta name="permissions:contacts:description" content="Required for > auto-completion in the share screen"> > <meta name="permissions:contacts:access" content="read"> > <meta name="fullscreen" content="true"> > <meta name="release_notes:1.0" content="Bugs fixed. New exciting effects. > Ready for an official release!"> > <meta name="release_notes:0.5" content="First alpha version with still some > bugs but already fun!"> > > > When writing this I was surprised how well existing functionality fits (and > thus how much "NIH" can be avoided). > > The only bit that didn't seem natural fit was <meta> for permissions, so > maybe a better element needs to be invented for it: > > <permission for="contacts" access="read"> > <meta name="description" content="Required for…"> > <meta name="description" lang="pl" content="Wymagane do…"> > </permission> > > or perhaps made generic: > > <metagroup name="permissions"> > <metagroup name="contacts"> > <meta name="access" content="read"> > <meta name="description" content="Required for…"> > <meta name="description" lang="pl" content="Wymagane do…"> > </metagroup> > </metagroup> > > -- > regards, Kornel >
PGP.sig
Description: This is a digitally signed message part