Warning:
This wiki has been archived and is now read-only.
Open issues of API doc for LC
From Media Annotations Working Group Wiki
Open issues of API doc for going LC
- (1) The text about the two implementation scenarios seems out of place — what is its relationship with the WebIDL above? Isn't it introductory? The second scenario contradicts earlier statements according to which this is a client API, and confuses me as to the exact scope of the specification — is it not just intended as a JS API to get metadata out of documents? (It's done. but there are a few problems related with browsers.)
- (2) In addition to more detail in the descriptions, examples would help. For instance, converting Mozilla's File API + EXIF parser to your API might be interesting. (by Florian)
- (3) Title: Why just "Album title" and "Song title"? A *lot* of other things can have titles. (by wonsuk)
- (4) Section 2.3.2.3 CreationDate (by Wonsuk and John)
- you talk about both "CreationDate" and "Date" here. If you want this value to have a type of e.g. "creation date" and "publish date", it should not be called "CreationDate", but only "Date". -also, this may possibly return a list of dates rather than just one value
- (5) Section 2.3.5.2 Policy (The example for link attribute should be added by Florian)
-replace "Policy" with "License" as it is called in the Ontology (or do it the other way roung) -replace "policy" attribute with "value" -add a "link" attribute (or something similar) with a link to the license text
interface License: MAObject { attribute DOMString value; attribute DOMString link; attribute DOMString organization; attribute DOMString type; } <pre> - example needs to map the fields *(6) Section 2.3.8.1 FrameSize '''(by wonsuk)''' - Request should use the correct property name: replace "technical-properties" with "frameSize" *(7) "Section 2.3.8.4 Format '''(by wonsuk)''' - doesn't need a language attribute - replace ""StringObject"" with ""Format"" - interface should be: <pre> interface Format: MAObject { attribute DOMString value; }"
- (8) "Section 2.3.8.5 Samplingrate (by wonsuk)
- replace ""UnsignedLongObject"" with ""Samplingrate"" - example should have a common samplingrate for audio, e.g. 44100 Hz"
- (9) "API for retrieval of reason of an error" Is there a reason to use this approach instead of an error callback or an exception? Note that what getDiagnosis() is supposed to be called on is unclear. (by Chris and wonsuk)
- (10) The interfaces aren't clear as to whether they have constructors, in what scope, etc. (by Florian)
- (11) There are pretty much no conformance clauses, normative statements, testable assertions, etc. This is a concrete API, it must be testable. (by John)