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
> 

Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to