Re: [ACTION-472] Compile list of status code issues / additional issues

Thanks Martin for your valuable efforts.

I split your suggestions as three categories like below.

[1] status code replacement 206 with 200

[2] JSON exaplme including only associated value

[3] Ont document sync with JSON document


During the call, we decided to deal with both [1] and [2] categories
as soon as possible since these are related to the API  doc movement.
After resolving those issues, we should ask Director for the API doc
movement. Then [3] will be discussed later on.

MAWG members:
Please review Martin's suggestions particularly [1] and [2], and
comments and feedbacks on the mailing list immediately. We will
discuss them in the next teleconference and move the API doc forward
PR accordingly.


Martin:
Regarding [2], could you give us more JSON examples like DIG35, Dublin
Core, EBUCore, Exif, ID3, IPTC, LOM, MediaRSS, DMS-1, TV-Anytime,
TXFeed, XMP, YouTube ?  That might be very helpful for us to resolve
this issue quickly.



Regards, Daniel.


On Tue, Jun 5, 2012 at 7:52 PM, Höffernig, Martin
<Martin.Hoeffernig@joanneum.at> wrote:
>
>
> Dear all,
>
>
>
> I have reviewed the API status codes [1] in the normative JSON files of the
> testsuite implementation [2] and I found some issues that should be
> addressed.
>
> All of these issues are related to the usage of status code 206 (partial
> content).
>
> For me, 206 is misused in many cases since its semantics is possibly not
> quite clear.
>
>
>
> I think, 206 should be returned in cases where only partial data of
> available data for a media resource is returned.
>
> For example, when requesting the FrameSize property and Height will be
> returned only, while data about Width is available as well should result in
> status code 206.
>
> On the other side, when retrieving a location property for which the name of
> the location (locationLabel) is available only - further information like
> latitude and longitude is not available –
>
> I suggest to return status code 200 (OK), since all the available
> information will be returned.
>
>
>
> Taken my interpretation of the usage of satus code 206 into account, I
> suggest to change the status code 206 to 200 in for the following
> MediaAnnotation objects:
>
> DIG35:
>
> Location, Copyright
>
> DublinCore:
>
> Contributor, MADate, Location, Relation, Copyright
>
> EBUCore:
>
> Locator, Location, Creator, Relation, TargetAudience, NamendFragment,
> Fragment, FrameSize
>
> Exif:
>
> Copyright, FrameSize
>
> ID3:
>
> Contributor
>
> YouTube:
>
> TargetAudience
>
> IPTC:
>
> Location, Copyright, Policy, TargetAudience, Fragment, FrameSize
>
> LOM 2.1:
>
> FrameSize
>
> Media RSS:
>
> Location, Rating, Copyright, Policy, FrameSize
>
> TV-Anytime:
>
> Relation, TargetAudience
>
> TXFeed:
>
> Copyright
>
> XMP:
>
> Contributor, Creator, MADate, Location, Rating, Relation, Copyright, Policy
>
> YouTube:
>
> TargetAudience
>
>
>
> Furthermore, I suggest that in a JSON response, MediaAnnotation objects
> should only contain attributes with associated values.
>
> For example, in the following MediaAnnotation object, the attributes
> language, fragmentIdentifer, typeLink, and typeLabel should be removed,
> since no value is available for these attributes.
>
> { "Title" : {
>
>     "propertyName" : "title",
>
>     "value" : "Oasis Concert Stage @ I Am A Walrus",
>
>     "language" : "",
>
>     "sourceFormat" : "dig35",
>
>     "fragmentIdentifier" : "",
>
>     "mappingType" : "exact",
>
>     "titleLabel" : "Oasis Concert Stage @ I Am A Walrus",
>
>     "typeLink" : "",
>
>     "typeLabel" : "",
>
>     "statusCode" : 200
>
>     }
>
>
>
> This issue applies to many MediaAnnotation objects in following documents:
>
> DIG35, Dublin Core, EBUCore, Exif, ID3, IPTC, LOM, MediaRSS, DMS-1,
> TV-Anytime, TXFeed, XMP, YouTube
>
>
>
> Moreover, while examining the status codes, I made the observation that some
> JSON response documents are not in sync with the corresponding ontology
> examples.
>
> Therefore, MediaAnnotation objects include data which are not present in the
> corresponding ontology document.
>
> I thought that the ontology documents should be the basis for the JSON
> responses?
>
> Concerning formats:
>
> EBUCore, Exif, ID3, LOM, MediaRSS, TV-Anytime
>
>
>
> [1]:
> http://www.w3.org/TR/2011/WD-mediaont-api-1.0-20111122/#api-status-codes
>
> [2]:
> http://www.w3.org/2008/WebVideo/Annotations/wiki/TestSuite_implementation
>
>
>
> Hope my observation scan help to improve the JSON documents.
>
>
>
> Best,
>
> Martin
>
> --
>
> Martin Höffernig
>
> Audiovisual Media Group
>
> DIGITAL – Institute for Information and Communication Technologies
>
>
>
> JOANNEUM RESEARCH Forschungsgesellschaft mbH
> Steyrergasse 17, 8010 Graz, AUSTRIA
>
> phone:  +43-316-876-1184
>
> general fax: +43-316-876-1191
>
> web:    http://www.joanneum.at/digital
> e-mail: martin.hoeffernig@joanneum.at
>
>



-- 
Soohong Daniel Park
Samsung Electronics, SWC

Received on Tuesday, 5 June 2012 12:09:18 UTC