- From: Paul Kinlan <paulkinlan@google.com>
- Date: Wed, 5 Sep 2012 03:12:35 -0700
- To: Norifumi Kikkawa <Norifumi.Kikkawa@jp.sony.com>
- Cc: "public-web-intents@w3.org" <public-web-intents@w3.org>
- Message-ID: <CADGdg3Dn815c49Tp8Woo_XtbmckGD_QYMJs3Nqe4bkfFdn=T+w@mail.gmail.com>
Hi, Text/uri-list is for sharing URLs, it doesn't care what the content is behind that URL. Think of a button that is in the browser that just says share the URL in then address bar. It could be a page, movie or PDF file. To be very explicit abut sharing a movie file your data type would be video/mpeg for example. Then a URL that is passed in would be a pointer to a video file. Given have just removed extras, the data attribute in the intent object will need to carry extra data, so I will share a link to a document that describes how the payload should appear exactly for then share intent across multiple data types. P On 5 Sep 2012 01:22, "Norifumi Kikkawa" <Norifumi.Kikkawa@jp.sony.com> wrote: > Hi all, > > I found that some media related intents actions can handle not only > binary content but also url list. For example, > http://webintents.org/share, http://webintents.org/pick assume the > text/url type. > > Although I believe this is also useful in case of a single big content > (e.g. > movie), I concern that the "text/url" type seems not enough > to determine the capability/requirement of services. How can the intent > registration tag say "I can provide a url for movie, but for contact > info"? How to pick a movie by url? > > My question is : > 1. Can a URL be used for such porpose in web intents? > 2. Does it make sense to add some mechanism to expose more detail > info in "text/url" case? > > A URL may reveal its origin, but this is another issue... > > Thanks, > Kikkawa > > --------------------------------------------- > Norifumi Kikkawa <Norifumi.Kikkawa@jp.sony.com> > Section 1 > Network Technology Dept. > Information Technology Development Division > System & Software Technology Platfotm > Sony Corporation > (TEL) +81 50 3750 3953 > ----------------------------------------------- > > >
Received on Wednesday, 5 September 2012 10:13:04 UTC