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

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.
>
>

Received on Thursday, 10 February 2011 08:57:45 UTC