W3C home > Mailing lists > Public > public-web-intents@w3.org > November 2011

Re: Web Intents - Suggested Deliverables (part 2)

From: Robin Berjon <robin@berjon.com>
Date: Tue, 22 Nov 2011 11:22:06 +0100
Cc: public-web-intents@w3.org
Message-Id: <27CDF42D-9FFB-4145-88DE-0648696FF0AB@berjon.com>
To: Paul Kinlan <paulkinlan@google.com>
On Nov 22, 2011, at 02:56 , Paul Kinlan wrote:
> Yes we discussed the intent tag on public-webaps [1], or at least the
> reason about it be declared in the html over a manifest file.
> 
> I don't believe the meta element was directly discussed, but the
> reasoning behind our choice of new tag is: 1) it is a new platform
> feature with elements and attributes that don't fit in the meta name
> and content model
> 2) encoding data into the content attribute is error prone
> 2a) parsing data encoded in the content attribute will be error prone
> 3) if we chose not to encode, we would introduce a lot of extra
> attributes that are very specific to one case
> 4) it can be validated by parsers and by eye with greater ease
> 5) a separate DOM element can have those properties exposed
> individually via scripting, for instance there would be a
> DOMIntentElement that can be compared as an instanceof and also have
> access to the specific attributes.
> 
> [1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1518.html

I don't want to rathole into syntax right at the start but there's one thing that bothers me: the <intent> element is defining authoritative processing metadata for *another* resource. That seems like an excellent recipe for screwing up.

Consider this scenario: I am developing a site for Cryptozoology Anonymous, and include a service which allows to report sightings of unicorns and dahuts. That service sits at http://cryptonymous.org/report.html. I link to it from another page using:

    <intent action="http://example.org/report" type="text/plain" href="report.html"/>

Over time, I realise that it's more convenient if I add that link to multiple pages on my site.

Later, I reckon that text descriptions of sightings aren't all that reliable for some reason, and switch to accept image/*. I also note that it's nicer to inline the service page rather than open it in a new window. So I change my implementation completely, and update the links to be:

    <intent action="http://example.org/report" type="image/*" href="report.html" disposition="inline"/>

But of course, I forget a bunch of those. We now have intent registration links that are out of synch, for no gain and no good reason (that I can see) whatsoever. Or have I missed something (which is entirely likely)?

Detaching information that has a direct bearing on processing from the place where the processing occurs is generally a bad idea; the media type system is a good example of how wrong that can go.

If we rework this to have pages just linking to the service, and processing data in the service itself, we can have pages linking with:

    <link rel="intent" href="report.html"/> (or "service")

And then in report.html:

    <meta name="intent-action" content="http://example.org/report"/>
    <meta name="intent-type" content="image/*"/>
    <meta name="intent-disposition" content="inline"/>

Note that I'm not married to the above syntax, and the latter set of meta might still be best captured by and intent element (especially if there are good UCs for having an HTMLIntentElement). But at least it separates linking to an intent service from defining what that service's interface, which IMHO is a win.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 22 November 2011 10:23:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:45 UTC