See also: IRC log
<trackbot> Date: 15 September 2009
<florian> Zakim aaee is me
<scribe> Scribe: raphael
<scribe> scribenick: raphael
Proposal to accept minutes of last week telecon
No objections, minutes accepted
<pchampin> i volunteer
Pierre Antoine volunteered for scribing next week meeting
<trackbot> ACTION-124 -- Felix Sasaki to check - everybody responsible for a format: add a column describing syntactic information ("data types", see cable lab column "Type") to his table -- due 2009-06-16 -- OPEN
<scribe> -- ongoing
<trackbot> ACTION-134 -- David Singer to revise e-mail on issues/updates of property description -- due 2009-07-02 -- OPEN
<scribe> -- ongoing
<trackbot> ACTION-135 -- David Singer to update description of location to represent shot location -- due 2009-07-02 -- OPEN
<scribe> -- ongoing
<trackbot> ACTION-136 -- Joakim Söderberg to will refine the subtypes, like ma:contributor, ma:publisher etc. -- due 2009-07-02 -- OPEN
Joakim: I put a link on the wiki
<trackbot> ACTION-136 Will refine the subtypes, like ma:contributor, ma:publisher etc. closed
<trackbot> ACTION-148 -- WonSuk Lee to start work and collaboration on the API draft document -- due 2009-07-03 -- OPEN
Wonsuk: you have all received the
email from Florian about the issues
... I suggest we discuss these issues
Joakim: we will discuss them in the next agenda item, we can close this AP
<trackbot> ACTION-148 Start work and collaboration on the API draft document closed
<trackbot> ACTION-151 -- Werner Bailer to formulate an answer on the feed back from PFWG (Protocols and Formats WG) -- due 2009-09-08 -- OPEN
Werner did that and we sent our review
<trackbot> ACTION-151 Formulate an answer on the feed back from PFWG (Protocols and Formats WG) closed
<trackbot> ACTION-152 -- Thierry Michel to look into web idl with victor and others -- due 2009-09-15 -- OPEN
Thierry: i start a thread
... Victor confirmed that WebIDL could be used, as we do video on the web
... no bindings for C++, but more tailored to web based applications so fit our purpose
... webidl is anyway close to idl
<trackbot> ACTION-152 Look into web idl with victor and others closed
<trackbot> ACTION-153 -- Joakim Söderberg to look into comments from werner on PFWG review -- due 2009-09-15 -- OPEN
Joakim: this action is connected to 151
<trackbot> ACTION-153 Look into comments from werner on PFWG review closed
<trackbot> ACTION-154 -- Joakim Söderberg to ask dave about the relationship of digital data exchange with Apple stuff, ID3, iTunesXML, etc -- due 2009-09-15 -- OPEN
Joakim: I have sent an email but
didn't get any answer
... leave it open
<scribe> -- ongoing
<joakim> I think this initial draft is a good starting point. But there are a few major things, i am wondering about:
<joakim> a) what about using interfaces as Victor proposed in ?
<joakim> b) did we choose one of the two possibilities for the API already (specific vs. common)? AFAIK only a few of us discussed these two different approaches .
<joakim> c) the datatypes are only "placeholder" for the finite datatypes, or? Because some of them do not fit their purpose i guess.
<joakim> d) as Victor already pointed out, WebIDL is in scope of our group, so we should bring this discussion to an end and use it...
<joakim> I think we have to discuss this draft more closely in todays telecon.
Wonsuk: I haven't received many
feedback yet on my document apart from Florian
... you can look at the API description (descriptive properties, identification, creator, content, etc)
... it includes the get and the set methods
it describes the interfaces based on toy implementation
Wonsuk: I suggest we discuss the issues mentioned in this document
Joakim: you want to discuss the categorization of the properties?
<chris> this classification conforms to the current mapping table
Wonsuk: do you have any questions about this?
Joakim: is this categorization so important ?
Document from Wonsuk: replace_URL
Could we please avoid to send documents to individual people? I will remind that this group operates under public, so use the public mailing list
<florian> +1 raphael
Joakim: now, we need to discuss the datatypes
Wonsuk: the meaning of the RESULT is ... [to complete]
Joakim: should we have a section discussing the return types?
Wonsuk: yes perhaps, we have String, RESULT, List, Date
<joakim> I guess it means: sucessful/unsuccesfull
Wonsuk: trying to explain again
what RESULT is ...
... it means we can parse the result ? (syntactically correct?)
<pchampin> RESULT is what is sometimes called 'status', right?
<joakim> while (RESULT)
Wonsuk: yes, for while and if, we can use RESULT, so looks like a boolean evaluation
<joakim> I agree
<joakim> 3. Data type Description
<joakim> 4. API Description
Wonsuk: discussion about identificatin of the co-editors
Joakim: Chris, Florian, Werner,
Victor?, Wonsuk: who is working on the sections 3 and 4?
... is it clear ? Perhaps someone should work on the datatypes, and someone else on the API
Chris: we haven't divided yet the
work as you suggested
... Wonsuk has made this first draft but we haven't discussed it yet among the editors
... now is the first time we discuss it
... I will comment it from now on
Joakim: my suggestion is to divide the work and not introduce bottlenecks
Chris: yes, I can live with that
<Zakim> pchampin, you wanted to discuss another question about datatypes
Pierre Antoine: I'm not quite sure it is safe to split the work between datatypes and API
scribe: my proposal would be to
split between properties which have structured values as
results versus non-structured
... I think this has been mentioned on the list
... but I haven't read yet the follow-up of this dicussion or any decision
scribe: I would vote for this way of splitting
Raphael: +1 for PA proposal
Chris: We haven't formally
defined which properties should have a structured or
... we have discussed that briefly at the last f2f, but we wanted to provide examples
... so we can decide which properties will get structured values or unstructured values
Chris: as far as I know, it is undecided yet for the properties
<pchampin> I think it is a pre-requisite to working on the actual API
<scribe> ACTION: chris and co-editors (wonsuk, florian, victor, werner) to come up for a proposal for a return type for all properties, i.e. structured or unstructured? [recorded in http://www.w3.org/2009/09/15-mediaann-minutes.html#action01]
<trackbot> Created ACTION-155 - And co-editors (wonsuk, florian, victor, werner) to come up for a proposal for a return type for all properties, i.e. structured or unstructured? [on Chris Poppe - due 2009-09-22].
Joakim: in your email Florian, you reference a proposal from Victor
Florian: this is an IDL example yes
Raphael: can we transform this same example into WebIDL?
Florian: I think we haven't yet
discussed enough Victor's proposal?
... how could we continue to discuss it?
<pchampin> from the WebIDL draft: "An interface is a specification of a set of interface members"
<pchampin> so it seems that WebIDL has interfaces as well
<pchampin> +1 for 1 method per property
Raphael: +1 too
Joakim: our idea is to indeed use
... How can we really be sure that the API will work?
Florian: should we build a
... that complements the abstract API documentation
<pchampin> I think Joakim rather means "test cases"
Florian: in the same spirit that the MPEG one
Joakim: who should provide reference implementation
Raphael: there is no rules for that
<pchampin> if the reference implementations have to pass the same test-cases, does this mean that they have to be in the same language?
Thierry: as raphael said, all W3C spec should go through implementations that pass test cases testing all features of the spec
Raphael: I suggest you look at the test cases developed by the Media Fragments WG as an example
<pchampin> I plan to update my toy implementation as well
Raphael: Media Fragments WG test cases: http://www.w3.org/2008/WebVideo/Fragments/wiki/TestCases
<pchampin> but it's in python, which I don't think will be the final language
<pchampin> hence my question...
pchampin, the language used for the implementation does not matter
the test cases should specify, if you encounter feature a, what should you do, and how can you test it does the right thing
Wonsuk: if we use WebIDL for the
API draft, do we have enough time given that we have not really
experts from this group
... it is just my concern
Joakim: i will forward the question to the editors, Chris, do you think it is doable?
Chris: I think it is, since
WebIDL is anyway very close to IDL
... I'm not (yet) a WebIDL expert
Raphael: I will remind that Doug Shelpers said that folks from his group would be happy to help us if we are stuck
Joakim: next meeting, we can discuss which datatypes to use for each properties
Pierre Antoine: I voted for one method per property, I think it is easier to work with
scribe: maybe for some
properties, we will give the choice to the developer to use a
simple or a structured value
... and in this case, we might provide 2 methods OR a parameter
Joakim: thanks for your thoughts
Joakim: meeting, next Tuesday
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/??? implementation/toy implementation/ WARNING: Bad s/// command: s/replace_URL/http://lists.w3.org/Archives/Public/public-media-annotation/2009Sep/0037.html Succeeded: s/avoir/avoid/ Succeeded: s/langauge/language/ Found Scribe: raphael Inferring ScribeNick: raphael Found ScribeNick: raphael Present: Joakim Chris Florian Raphael Veronique Pierre_Antoine Thierry Wonsuk Daniel Regrets: Tobias Werner Felix Agenda: http://lists.w3.org/Archives/Public/public-media-annotation/2009Sep/0033.html Found Date: 15 Sep 2009 Guessing minutes URL: http://www.w3.org/2009/09/15-mediaann-minutes.html People with action items: chris co-editors florian victor werner wonsuk[End of scribe.perl diagnostic output]