- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sun, 15 May 2011 23:27:29 +1000
- To: Joakim Söderberg <joakim.soderberg@ericsson.com>
- Cc: "Bailer, Werner" <werner.bailer@joanneum.at>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Hi Joakim, That's good to hear. I just wanted to point out that in the HTML WG features are only added when there is a particular use case. I was expecting that people here might have something concrete in mind, since I couldn't think of anything. But we can certainly wait until we do. Cheers, Silvia. 2011/5/15 Joakim Söderberg <joakim.soderberg@ericsson.com>: > Hello Silvia, > We know what the definition for a "use case" is, but in this context we have been using the term to distinguish between two major anticipated *uses* of our API specification. > > However your point is good, and if nor you can conceive specific uses cases I agree that we should not pursue this. We should just inform the HTML WG of our generic API and its rationale, so that one day hopefully implementers can reuse our work and adapt it to their specific needs. > > -Joakim > > > > > -----Original Message----- > From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Silvia Pfeiffer > Sent: den 11 maj 2011 23:33 > To: Bailer, Werner > Cc: public-media-annotation@w3.org > Subject: Re: ACTION-416: draft response on API concerns > > Hi Werner, > > > On Thu, May 12, 2011 at 1:11 AM, Bailer, Werner <werner.bailer@joanneum.at> wrote: >> Dear all, >> >> As discussed yesterday, here is a proposal for the response to the concerns raised on the API design. Joakim/Thierry please add on proposed next steps for collaboration. >> >> 1) As discussed in section 3 of the API document we discuss both scenarios implementing the API as a web service and in a user agent. The current example implementations are web service based (see [2]), which correspond to the use case of a media provider using an implementation of the API to publish metadata in the format compliant to the specification. However, we also considered the use case where existing metadata, published in any of the formats considered in the mappings, needs to be accessed by a user agent and processed, possibly together with metadata in other formats. The contributors at University of Passau are currently working on a Firefox plugin implementing the API for that purpose. Unless one assumes the existence of a web service doing the mapping, we think that this use case requires the API and mapping functionality on the client side. > > None of this is a use case. A use case is when you describe a user doing things. For example, your mother while surfing the Web and watching videos having to look at the metadata for... some purpose... > This needs to be a use case that is general, so not specific to a single Website (because on such a Website you can just extract the metadata on the server and present it to the use, such as Flickr does for images). It also needs to be for HTML specifically, because if it's not for HTML, it's not relevant to the HTML Working Group (which is why I had this long discussion about ePub). > > I've wrecked my brain and am not able to come up with such a use case. > Why would you need a JavaScript API for it? If nobody can come up with a good use case, it really isn't worth pursuing this at this stage with the HTML WG. Only when we come across such a use case would we ask for such an API. We can wait until then and pursue the other use cases that this WG is working on. It doesn't invalidate the work here. > > Cheers, > Silvia. > > > >> 2) The API is not only targeted at browsers, but implementation in the browser is one of the cases. We do agree that interaction with the implementers is crucial, and we have made several attempts to start a discussion with browser vendors, but with little feedback. The fact that the spec does not only target browsers also explains that specific details as mentioned in concern 3 are not included. We would expect that such details go into a separate document, built on top of the API spec. >> >> Best regards, >> Werner >> >> [1] >> http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1. >> 0.html [2] http://www.w3.org/2008/WebVideo/Annotations/#Implementa >> >>> -----Original Message----- >>> From: public-media-annotation-request@w3.org [mailto:public-media- >>> annotation-request@w3.org] On Behalf Of Henri Sivonen >>> Sent: Freitag, 06. Mai 2011 13:39 >>> To: tmichel@w3.org >>> Cc: public-html@w3.org; 'Silvia Pfeiffer'; public-media- >>> annotation@w3.org >>> Subject: Re: follow up on the discussion in HTML5 about metadata >>> access >>> >>> On Wed, 2011-05-04 at 14:18 +0000, Thierry MICHEL wrote: >>> > The MAWG would like to have a better understanding of your concerns. >>> > Could you please explain more deeply what are your issues for >>> > access >>> to >>> > these metadata, and which requirements are not satisfactorily >>> addressed >>> > by the MAWG API. Could you provided a few use cases we could study >>> and >>> > see how our API fits. >>> >>> At this time, I have two general concerns and one specific concern. >>> >>> My general concerns are: >>> 1) It's not clear to me that the APIs are motivated by strong use >>> cases. What are the use cases that are considered to justify the >>> implementation of these APIs? Can those use cases be addressed by >>> other means? >>> >>> 2) I'm concerned that designing APIs (or specs in general) for a >>> class of products (browsers in this case) without the participation >>> of implementors of products from that class of products leads to >>> designs that aren't suitable for the class of products. >>> >>> My specific concern is: >>> 3) The API spec doesn't seem to cover how the API should behave when >>> the API is called to request data that is in a file that hasn't been >>> retrieved from the network yet. (That there is this sort of basic >>> issue is related to my concern #2.) >>> >>> -- >>> Henri Sivonen >>> hsivonen@iki.fi >>> http://hsivonen.iki.fi/ >>> >> >> > >
Received on Sunday, 15 May 2011 13:28:17 UTC