RE: Gallery API draft review request

> On Fri, May 4, 2012 at 10:07 AM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:
> > Greg,
> >
> > Is there a way in your proposal to add an attribute "readonly attribute
> DOMString headers[];" so that an array of headers related to the content
> (as metadata) can be provided as well?
> 
> Those can be provided as extra data. I specified one such header
> ('url'), and suggested another ('filename'), but there could be more.

I think it'd be reasonable to align with the media annotation work
(http://www.w3.org/TR/2012/REC-mediaont-10-20120209/#core-property-lists)
since it had been considered many media formats and metadata types already
(http://www.w3.org/TR/2012/REC-mediaont-10-20120209/#metadata-mapping-
table).

Then, it would be like the following:

dictionary mediaData {
  DOMString identifier;  // Unique ID
  DOMString title;
  any language;            // Lanaguage of the content
  DOMString locator;     // URL of the resource
  any contributor;
  any creator;
  Date date;
  Position location;
  DOMString description;
  any keyword;
  any genre;
  any rating;             // Data type should be defined
  any relation;          // An attribute that identifies a resource that
the current resource is related with.
  any collection;       // The name of the collection from which the
resource originates.
  DOMString copyright;
  any policy;
  any publisher;
  any audience;
  DOMString fragment;
  DOMString namedFragment;
  any frameSize;                // Frame size of the resource (e.g. width
and height: 720 X 480)
  any compression;
  Number duration;
  DOMString format;           // MIME type of the resource
  Number samplingRate;       // Audio sampling rate
  Number frameRate;           // Video frame rate
  Number averageBitRate;    // Average bit rate
  Number numTracks;
  any tag;
}

One thing I would like to add is "tag" field which is most commonly used by
existing services.
The data type for each of the field is one big discussion topic, I suppose.

> One piece of feedback we've gotten on the API is that we should be
> able to enumerate the extra data fields (i.e. returning a dictionary
> there instead of the getExtra() function). My concern about that is
> that it's a bit ambiguous how that relates to Javascript, and that's
> why we don't see APIs use that pattern. Is there a good way around
> that difficulty?

I also think it'd very nice if we provide a way to enumerate what fields
are delivered. Let me also think about it.


> > Thanks,
> > Bryan Sullivan
> >
> > -----Original Message-----
> > From: Greg Billock [mailto:gbillock@google.com]
> > Sent: Thursday, May 03, 2012 4:40 PM
> > To: Wonsuk Lee
> > Cc: Jungkee Song; DAP; public-web-intents@w3.org; ÀÌ¿ø¼® Lee
> > Subject: Re: Gallery API draft review request
> >
> > I have a question about synchronizing this work with the proposal for
> > passing MIME types through web intents at [1].
> >
> > There I describe how to prepare MIME typed data on the client side,
> > and didn't address returning data from the service as MIME type. I
> > think it'd be best to coordinate this so that any MIME type specifier
> > produced a common expectation for any action. For example, something
> > that builds on this would be:
> >
> > A service returning MIME type data MUST prepare it in a dictionary as
> follows:
> >
> > dictionary MimeTypeData {
> >  readonly attribute any content;
> >  readonly attribute DOMString url;
> >  readonly attribute DOMString filename;
> >  // (other attributes may be present?)
> > };
> >
> > If the MIME type is binary (application/*, image/*, video/*, audio/*),
> > then the "content" field MUST be of type Blob. If the MIME type is
> > text (text/*, message/*, multipart/*), then the "content" field MUST
> > be text.
> >
> > Either the content or the url field may be filled.
> >
> > If present, the "filename" field may refer to the service-side
> > filename of the resource passed back, as a hint to the client.
> >
> > ---
> >
> > This mimics the usage I described for passing MIME types. Do you agree
> > that something like this would be a good overall MIME passing
> > convention? If so, do you want to add this to the wiki page [1]?
> >
> >
> > [1] http://www.w3.org/wiki/WebIntents/MIME_Types
> >
> >
> >
> > On Thu, May 3, 2012 at 1:59 AM, Wonsuk Lee <wonsuk73@gmail.com> wrote:
> >> Hi. All.
> >>
> >> Below link is pretty version ;)
> >> https://dvcs.w3.org/hg/dap/raw-file/16185b62381d/gallery/index.html
> >>
> >> best regards,
> >> Wonsuk.
> >>
> >> 2012/5/3 Jungkee Song <jungkee.song@samsung.com>:
> >>> (DAP) ACTION-533: Jungkee Song to Gather use cases for Gallery API
> >>>
> >>> Hi,
> >>>
> >>> Since the last DAP F2F meeting, Wonsuk and I have prepared a draft for
> the
> >>> Gallery API, a shelved item for a while.
> >>>
> >>> In this draft work, we propose to use Web Intents to locate media
> galleries
> >>> (no matter whether they are on web or local) and deliver media
> contents
> >>> with metadata. We think that the advantage of this approach is that it
> >>> makes integrating with popular services like Flickr, Youtube,
> SoundCloud a
> >>> lot easier. We tried to stay with the simple and practical use cases.
> >>>
> >>> Your review on the draft will be appreciated. Especially, see the
> section
> >>> "3.2 Discussion".
> >>> Let's discuss.
> >>>
> >>> * I uploaded the file in the DAP repo:
> >>> https://dvcs.w3.org/hg/dap/gallery/index.html
> >>>
> >>>   Dave, Dom,
> >>>     Could you let me know how to put this file on the main page?
> >>>
> >>>
> >>> Regards,
> >>> Jungkee
> >>>
> >>>
> >>> Jungkee Song
> >>> Samsung Electronics
> >>
> >>
> >>
> >> --
> >>
> >> =========================================
> >> ÀÌ ¿ø ¼® (Wonsuk, Lee) / Principal Engineer, Ph.D
> >> SAMSUNG ELECTRONICS Co., LTD. (ß²àøï³í­)
> >> Mobile: +82-10-5800-3997
> >> E-mail: wonsuk11.lee@samsung.com, wonsuk73@gmail.com
> >> http://www.wonsuk73.com/, twitter: @wonsuk73
> >> -----------------------------------------
> >> Inspire the World, Create the Future !!!
> >> =========================================
> >>
> >

Received on Wednesday, 23 May 2012 11:51:05 UTC