http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100608/

> This specification defines a client-side API to access metadata
> information related to media resources on the Web. The overall
> purpose of the API is to provide developers with a convenient

I'd write "this API" instead of "the API" here and in the rest of this document.
-> OK

> access to metadata information stored in different metadata formats.
> Thereby, the Media Ontology Core Properties will be used as a pivot

"Thereby" is an odd word.
-> removed
And given that you haven't introduced <MOCP>
until here, the entire sentence seems problematic. Typically I'd
expect someone to introduce briefly (one or two sentences) what
something (MOCP) is before saying that it will be used.
-> still no sentence introducing the MOCP, nor the lik with the Media Ontology, maybe adding "from the Media Ontology" would help? I don't think that we need a full 2 sentences to introduce the ontology and the properties as they are hyperlinked from this spot in the document.

> vocabulary in the API. The description of relations between these
> core properties and the metadata formats in scope (1.2 Formats
> in scope) are stored in the Media Ontology in order to provide

Does "Media Ontology" here refer to the same thing as MOCP earlier?
if it does, then you should indicate that you intend to use that short
form when you introduced it, if not, then you just used an undefined
term.
-> so indeed, we should add the MOCP from the Media Ontology, and link to the Media Ontology by a hyperlink at the first mention, otherwise it is indeed confusing.

> cross-community data integration. The API is described using the
> interface definition language [WEBIDL]. The decision to use Web IDL,
> which offers bindings for ECMAScript and Java, can be based on the
> Use Cases and Requirements for Ontology and API for Media Resource
> 1.0 [MEDIA-ANNOT-REQS]. This document clearly states that the focus
> for this API lies on multimedia services on the Web.

this should be "lies with" or "relies on"
-> changed to "is", ok

> The API serves as a mediator between a developer and the underlying
> Ontology for Media Resource 1.0 [MEDIA-ANNOT-ONTOLOGY] with

drop "underlying", ontologies do not live below developers.
-> ok

> the goal to support interoperability between metadata formats. It offers

change "to support" to "of supporting"
-> "with the goal supporting interoperability" to be changed to "with the goal OF supporting interoperability"

> operations to retrieve particular metadata informations represented in
> a certain metadata format related to media resources on the Web.

> This document is being published with the aspiration to gather wide

You don't want "aspiration", you could replace "published..to" with
"published in order to"
-> ok, dropped

> feedback on the yet available API design.

This doesn't make sense.
-> ok, dropped

> 1.1 Formats in scope
> Refers to the formats in scope of Ontology for Media Resource 1.0.

> 1.2 Formats out of scope
> Refers to the Formats out of scope of Ontology for Media Resource 1.0.

> 1.3 Terminology
> In this document the terms "Media Resource", "Property", "Mapping"
> and "Property value type" are to be interpreted as defined in Section
> 2 of Ontology for Media Resource 1.0.

> 2. Design consideration
> We consider two scenarios where the API could be implemented:
> either in a user agent (scenario 1) or as a web service (scenario 2).
> The two scenarios are shown in the figure.

There's no figure here. Please name it (the figure is 2 paragraphs away).
-> ok, done

> Scenario 1: User agent
> The API is implemented in a user agent (e.g., browser or browser plugin)
> and exposed as a JavaScript API (using the WebIDL JavaScript binding).
> The user agent includes the components for metadata access (possibly

drop the "the" after "includes" and add an "and" before "possibly"
-> ok

> extraction) and mappings for a supported set of formats. The metadata
> sources (the media resource and/or metadata document(s)) must be
> retrievable and access (establish connection, retrieval) of the metadata

change "of" to "to".
-> ok

> sources is handled by the user agent.

Security considerations?
-> I don't know whether security considerations were added to the document elsewhere? Maybe they could be mentioned here?

> Scenario 2: Web service
> The API is implemented as a Web service. Such an implementation would
> be typically used by a non-UI client, such as an agent harvesting metadata.
> However, the API could be also accessed from a user agent, and used the
> same way as described in scenario 1 by the help of a JavaScript library for

change "by" to "with"
-> not done yet, but not sure whether it should be changed...

> accessing the web service.


> At the back-end of the web service, this scenario

you don't usually write 'back-end of the web service'.
and i'm not sure what this means.
-> ok, changed

> also allows supporting a media repository (e.g. content provider's archive
> database, movie store) from which the user agent could directly retrieve
> metadata sources and which might have a custom metadata format not
> supported by a user agent.

This doesn't make sense and is incredibly long for a single "sentence".
How could a user agent *directly* retrieve formats it doesn't support?
-> ok, changed

> In contrast to an integrated component (see scenario 1), an implementation
> of the API in a web service could do more complex mappings on the fly as

replace "as" with "than"
-> ok

> a component integrated in a user agent, and can be more flexible
> (e.g., supporting additional formats).

> Overview of different API options.

This alt text is woefully insufficient. It doesn't indicate that it's
a diagram.
-> add the mention that it's a diagram?
"JavaScript" is one word, not two.
-> done

> In both scenarios, the access to the metadata properties needs the following stack of components:

drop the first "the"
-> ok

> * An implementation of the API for Media Resource (as defined in this
> document), which providers the actual getter methods for the properties.
> * An implementation of the mappings from a specific source format to the
> properties of the media ontology (as defined in Ontology for Media Resource 1.0).

Why isn't "Media Ontology" written as a proper noun here?
-> write "the Ontology for Media Resource 1.0." or "the Media Ontology", whichever is consistet with the rest of the document.

> * A format specific API to access the metadata. This can be an API for
> accessing a metadata document describing a media resource (e.g. an XML
> parser and a set of XPath statements) or an extractor to read metadata
> embedded in the media resource (e.g. a library to read EXIF information from
> JPEG images).

> In order to define the context on which the API for Media Resource is working,

change "on" to "with"
-> changed but would it not be more relevant to write "in"? 
and "working" to "applied"
-> ok

> it is assumed that there is at least a unidirectional reference from the media

why are you assuming things? -- this is an editorial complaint, the
statement needs to be active "one needs at least ..."
-> "In order to define the context with which this API is applied, at least a unidirectional reference from the media resource to the metadata document or vice versa." to be changed to "In order to define the context with which this API is applied, at least a unidirectional reference from the media resource to the metadata document or vice versa IS NEEDED."

> resource to the metadata document or vice versa. If this is not the case such > a
> reference needs to be provided by the web application (scenario 1), web 
> service
> (scenario 2) or media repository (scenario 2).

> 3. API Description
> The JavaScript examples in this document will only work if the API is implemented
> by the browser.

> The API exists of a number of interfaces, described using Web IDL.

change "exists" to "consists"
-> ok, changed

> Implementations of the API should provide objects implementing the different
> interfaces. The entire description can be found in Appendix A. The API is 
> contained
> within the MediaResource interface within the mawg module.
> Objects implementing this interface provide the necessary methods to access
> metadata properties of a Media Resource. The object holds methods to identify
> the actual Media Resource and the metadata sources. All properties can be
> accessed through a specific operation getProperty.

... specific operation: getProperty.
-> even though there is a change of font, maybe the ":" would be a good idea indeed?

> When an attempt to read a property fails, diagnostics information can be       > obtained
> using a diagnosis operation. Subtypes in the API are relevant for those  
> properties
> mentioned in 4.1.3 Core properties of Ontology for Media Resource 1.0.

> Lastly, methods are available that allow to iterate through the available 
> metadata.

change "to iterate" to "iteration"
-> not in the text anymore, so should be changed :)

> Next, the different interfaces and exposed methods are discussed.
> Finally, examples of the usage of the API can be found in section 4.

You can't use Lastly, Next and Finally as a set. -- And I'd suggest
that you avoid using "Lastly" entirely.
-> ok, Lastly removed.

> 3.1 MediaResource interface
> The MediaResource interface offers a number of operations that allow
> accessing the metadata of a Media Resource.

... provides a number of operations
-> ok
to access the metadata ...
-> not done

> Example on how to introduce this in HTML5 by making the HTMLMediaElement

change "on" to "of"
-> not in the document anymore

> inherit from the MediaResource interface:

> interface HTMLMediaElement : MediaResource, HTMLElement {...}

It seems like you're invading the HTML WG's namespace....
-> not in the document anymore

> As shown, the getElementsByTagName returns a HTMLMediaElement
> which inherits from the MediaResource interface. The getProperty
> method is part of this interface so the returned element has an
> implementation of this method. By calling the getProperty method
> with the argument "title" we can retrieve the title of the corresponding
> media resource.

I don't think that getProperty is a good name for something that might
go into HTML DOM.
-> changed to getMediaProperty, is it consistent with other places?

> interface MediaResource {
> boolean selectMAResource (in DOMString mediaResource, in optional MetadataSource[] metadataSources);
> MAObject[] getProperty (in DOMString propertyName, in optional DOMString fragment, in optional DOMString sourceFormat, in optional DOMString subtype, in optional DOMString language);

getProperty is singular, it shouldn't be returning an array. Perhaps
getMAProperties()?
-> can't find it in the document.

> DOMString[] getPropertyNamesWithValues (in optional DOMString sourceFormat,
> in optional DOMString language, in optional DOMString fragment);

This is in plural, but again, it's icky.
-> changed the name

> DOMString[] getSourceFormatsWithValues (in optional DOMString language);

This is in plural, but again, it's icky.
-> dropped the method

> DOMString getDiagnosis ();

This is awful. Typically such things should be attributes. The
attribute name should be meaningful, this is not.
-> can't find it in the document

> DOMString[] getOriginalData (in DOMString sourceFormat);

Data is a plural, but this should probably be getMAOriginalData or
getOriginalMAData ...
-> changed the name

> getDiagnosis
> This operation allows to retrieve the status code(e.g., the getProperty 
> operation returning a null value). See Section 4 for details.

I believe you should be using "function" or "method" instead of
"operation" (global comment).
-> still 51 "operation" in the document

Change "to retrieve" to "retrieval of" (globally).
-> changed

You're missing a space between "code" and "(".
-> changed

And splitting a return
value out of a function for the null case is not very DOMish,
typically we'd use an Exception with the information in the exception
object. Why aren't you?
-> don't know whether this was changed

> getProperty
> This operation allows to retrieve the value of a certain property. The 
> specific
> property is passed as an argument and a list of objects is returned that hold
> the
> values according to the requested property. These objects implement the
> MAObject interface, described in (MAObject interface). Depending on the
> requested property, the returned objects implement a different sub-interface
> (inheriting from the MAObject interface).

> Requesting for the title gives back an array of MAObjects implementing the

This seems to be the first introduction of "title" (at least locally),
and it isn't marked up. It doesn't make sense. Perhaps:

Requesting "title" returns an array of MAObjects implementing the
[pre]Title[/] interface...
-> changed

> Title interface,

> requesting the creator results in MAObjects implementing the Creator interface
> and so on. These interfaces are described in section 3.5 to 3.12.

> propertyName DOMString ✘ ✘
>	This argument identifies the property for which the values need to be
> retrieved.
> Optional arguments allow to refine the request

replace "to refine" with "refining" and add a period to this "sentence"
-> none of the two options in the document

> language DOMString ✘ ✔
>	This argument allows to identify the language of the metadata.
> Only if the metadata is available in the specified language, the values are
> returned.

Values for the metadata will only be returned if it is available in
the specified language
-> still 3 instances of the sentence to be changed in th document

> 3.5.1.1 Attributes
> type of type DOMString
> This attribute holds the type of the identifier, which can be filtered on in
> the
> getProperty operation. Possible values are " UMID" and "ISAN".

You have a space inside the quotes around " UMID" which seems odd.
-> changed

> 3.5.2 Title interface
> Title interface is used as the specific return type of
> MediaResource.getProperty
> method which has "Title" as a value of propertyName parameter.

the earlier request seemed to be for 'title', not 'Title' ...
-> changed

> 3.9.2.1 Attributes
> link of type DOMString
> This attribute holds a link to the license if it is externally available.

Why is this a string instead of a url type?
-> can't find the spot in the document the remark deals with

> organization of type DOMString
> This attribute identifies the organization that issued the license.

> type of type DOMString
> This attribute holds the actual type of the policy, which can be filtered on
> in the getProperty operation. Examples are "license", "access", and "privacy".

> value of type DOMString
> This attribute holds the description of the license.

> policy[0].value = "Attribution 2.5"
> policy[0].organization = "http://creativecommons.org/licenses/by/2.5"
> policy[0].type = "license"

Shouldn't organization be creative commons and the "link" property be
to the license?
-> not found in the document

> This section introduces a set of status codes for the defined API to indicate
> the system behaviour. It uses a subset of the HTML/1.1 [HTTP11] status

behaviour is the first word I can see which seems to be in en-GB
instead of en-US, I'd request that you consider whether your document
is in fact written in en-US and thus should use "behavior".
-> changed

> codes for general informations (e.g., bad request), but also system specific

information
-> still one instance of informationS in the document, to be changed

> ones (e.g., property not defined in source format). The specific status codes
> have been arranged in the HTML/1.1 [HTTP11] status codes categories.
> These codes can be retrieved by calling the getDiagnosis method.

> The set of status codes my be enlarged or changed in later versions of

Enlarged is odd.
Later versions of this document may include additional status codes or
other changes.
-> ok, changed

> this document. The numerical code range for the system specific status
> codes start with x62 (x = number of HTML/1.1 [HTTP11] status codes
> category and 62 = MA).

> Numerical Code Textual Description Example
> 200 Ok property delivered correctly

should be "OK"
-> changed

> interface MediaResource {
> //Operation for retrieval of the reason of an error

this is really unhelpful.
-> can't find it in the document

> DOMString getDiagnosis();

> interface Rating: MAObject, Language {
> attribute DOMString issuer;
> attribute short value;
...
> attribute DOMString type;

random indentation
-> ok

> interface Policy: MAObject, Language {
...
> attribute DOMString link;

random trailing whitespace
-> ok

...
> interface FrameSize: MAObject {
...
> attribute DOMString unit;

random trailing whitespace
-> ok

> Members of the Working Group are (at the time of writing, and by alphabetical order):

What about former members? :)

> Members of the Working Group are (at the time of writing, and by alphabetical order):

you already said that.
-> ok, removed