W3C home > Mailing lists > Public > public-media-annotation@w3.org > February 2011

Re: Moving the MA Ontology to 2nd LC, ma:compression, yet again

From: David Singer <singer@apple.com>
Date: Thu, 10 Feb 2011 10:54:33 -0800
Cc: public-media-annotation@w3.org, Joakim Söderberg <joakim.soderberg@ericsson.com>, Daniel Park <soohong.park@samsung.com>
Message-Id: <C1911879-6A87-46E0-8013-38673EAF5A77@apple.com>
To: tmichel@w3.org
Thierry

I repeat my apologies for the lateness of the objection, and the suggestion.  All I can say in my defence is that (a) I have been working on this issue, as evidenced by the emails, as hard as I can over the last two weeks and (b) I did not feel I could let the document advance when it only (i) partially included a (iii) previous, not current, and not agreed to, suggestion I had made.



On Feb 10, 2011, at 0:57 , Thierry MICHEL wrote:

> David,
> 
> Thank you for you review of the Ontology.
> 
> Do you find it appropriate to send a proposal at 1h08 AM a few hours before the publication?
> 
> Let me please remind you the procedure:
> 
> 1- For weeks I have asked during telecons, the Group to review the document before publication. I have also sent a reminder for *last chance* to review the document and mentioned that we will  take  the decision to move to 2nd  Last Call at the next telecon.
> I have received reviews from MAWG participants but not from you.
> 
> 
> 2- We have set a telecon last tuesday with an agenda [1] to discuss this issue of compression and to vote to publish the Ontology document to 2nd Last Call.
> Unfortunately you did not attend the telecon nor sent regrets, nor sent your opinion for moving or not to LC.
> 
> 3- Per W3C process for publications [3], publication are done only on Tuesdays and Thursdays. Regarding advance notice:
>    * if the checker reports issues that are confusing, please send the publication request no later than 3 business days prior to the desired publication date and in the request explicitly state which issues require Webmaster attention.
>    * otherwise, please send the publication request no later than 1 business day prior to the publication date (and 2 days is even better).
> 
> Therefore I MUST send to the sysTeam a publication request at least the day before the publication. I had done the tightest advance notice in order to publish today, as we wanted to publish before the F2F2.
> Therefore I had fixed a deadline for review on Wednesday night.
> 
> Publication at W3C is a tight procedure and needs a lot of steps, done by the Team contact, Chair and SysTeam. This is why it needs advance notice.
> 
> With these considerations, you can understand that an objection and a proposal sent at 1h08 AM, a few hours before the publication does not fit with the publication process.
> 
> Nethertheless, I have asked the Syteam to stop publication of this document, until we get a consensus on your issue. Therefore this will delay the track of the specification.
> 
> Best,
> 
> Thierry.
> 
> 
> 
> [1] http://lists.w3.org/Archives/Public/public-media-annotation/2011Feb/0017.html
> 
> [2] http://lists.w3.org/Archives/Public/public-media-annotation/2011Feb/0010.html
> 
> 
> [3] http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=lc-wd-tr#title-page-date
> 
> 
> 
> Le 10/02/2011 01:08, David Singer a écrit :
>> Hi guys
>> 
>> I have reviewed the ma:compression documentation, and we're in a strange state;  what's there is the semantics I suggested using a comma, not the revision following Jean-Pierre's suggestion using a "#"; and the syntax doesn't match.  We need to fix this before we send the document for review.
>> 
>> I just read through and found as many of the references for deriving the compression value, from as many formats as I could.  It wasn't possible for all of them, alas.
>> 
>> Here is another suggestion for this attribute;  it preserves both the possibility of a controlled vocabulary URI, and an uncontrolled vocabulary string, but by keeping them distinct we allow them to have precise syntax and semantics.  I believe that this (a) supports all the mappings -- at least the ones I can verify -- in the document and (b) supports all the expressed needs and use cases I have heard of.  We may the value a tuple of the two parts, both optional.
>> 
>> (Obviously we could fiddle with the formatting, documentation, names used here, and so on.)
>> 
>> * * * * *
>> 
>> compression
>> 
>> { (attName="identifier", attValue="URI" )?, (attName="indicator", attValue="String")? }
>> 
>> The compression type used. For container files (e.g., QuickTime, AVI), the compression is not defined by the format, as a container file can have several tracks that each use different encodings. In such a case, several compression instances SHOULD be used. Thus, querying the compression property of the track media fragments will return different values for each track fragment.
>> 
>> Either or both of two values may be supplied, an identifier and an indicator. The indicator is a free-form string; this can be used when a string is desired for user-display, or when the naming convention is lost or unknown.
>> 
>> The identifier is a URI that consists of a absolute-URU (RFC 3986, section 4.3)  and fragment (RFC 3986, section 3.5), that is, in the form absolute-URI#name. The absolute-URI identifies the naming convention used for the second parameter, which is a string name from that convention.  A URL is preferred for the URI, and if it is used, it (a) should contain a date in the form mmyyyy, indicating that the owner of the domain in the URL agreed to its use as a label around that date and (b) should be de-referencable, yielding an informative resource about the naming convention.
>> 
>> Note that this use of URIs with fragments also closely matches RDF (see<http://www.w3.org/TR/rdf-concepts/#section-fragID>).
>> 
>> Note that for some container files, the format parameter can also carry an extended MIME type to document this; see [RFC 4281] for one such instance.
>> 
>> * * * *
>> 
>> Hypothetical examples:
>> 
>> compression={"urn:example-org:codingnames2010#ITU-H264", "Advanced Video Coding"}
>> compression={"http://example.net/012011/standards/codecs.htm#G711"}
>> compression={, "Raw audio"}
>> 
>> where ITU-H264 and G711 are defined by example.org (who also defined a URN to identify their naming conventions), and by example.net (who use a URL to identify theirs). The second example gives only an identifier, and the third example has no identifier, only an indicator.
>> 
>> More concrete examples:
>> 
>> compression={ , "/3" }
>>   -- layer 3 compression in an ID3 block in an MP3 file
>> compression={"urn:x-ul:060E2B34.0401.0101.04020202.03020500", "MPEG Layer II/III"}
>>   -- layer 2 or 3 compression, SMPTE
>> 
>> compression={ , "AVC MP@L42" }
>>   -- AVC compression, Cablelabs
>> compression={ , "c125" }
>>   -- AVC compression, IPTC
>> 
>> compression={ , "34712" }
>>   -- JPEG 2000, TIFF
>> 
>> 
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>> 
>> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Thursday, 10 February 2011 18:55:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 10 February 2011 18:56:06 GMT