RE : Recapitulation of ma:format vs. ma:compression.

Hi Joakim,

Before being constructive the discussion needs to be well informed and educated.

I am not sure that you understand the issue.

I believe it is not reasonable to request URI only as best practice guidelines should be sufficient to explain that URI should be preferred.

I brought the URI issue by asking more attributes to support it as value and now I have to defend the interest of but one silent experts who originally asked for 'string'. That should be the role of the Chairman (your role).

Clearly all pairs URI/string would have to be removed. Do you get this right?????????

I think it is time to go public to warn people of the issue and of the completely inappropriate poll proposal.

Regards,

jean-Pierre


________________________________________
De : Bailer, Werner [werner.bailer@joanneum.at]
Date d'envoi : lundi, 7. février 2011 16:11
À : Joakim Söderberg; Evain, Jean-Pierre; 'David Singer'
Cc : tmichel@w3.org MICHEL; 'Tobias Bürger'; pa@champin.net; Daniel Park; Felix Sasaki
Objet : RE: Recapitulation of ma:format vs. ma:compression.

Hi Joakim,

> is a third alternative "slices of conformance"?

As stated in my earlier mail today, it depends on what you find in your source metadata. So you could have an implementation that conforms to the URI only case, but it will not be able to handle some of the metadata it encounters. This is less a question of the capabilities of the API (or a specific implementation) than of which metadata you are able to handle. If you can ensure a controlled environment, where you have URIs for all source metadata, you can have an API that will only provide the URI.

Best regards,
Werner

> -----Original Message-----
> From: Joakim Söderberg [mailto:joakim.soderberg@ericsson.com]
> Sent: Montag, 07. Februar 2011 16:04
> To: Evain, Jean-Pierre; 'David Singer'
> Cc: tmichel@w3.org MICHEL; Bailer, Werner; 'Tobias Bürger';
> pa@champin.net; Daniel Park; Felix Sasaki
> Subject: RE: Recapitulation of ma:format vs. ma:compression.
>
> I like the discussion to be constructive.
>
> Having already proposed to make a poll, we should think about the
> alternatives; is a third alternative "slices of conformance"? - quoting
> an expression from Felix.
>
> /Joakim
>
> -----Original Message-----
> From: Evain, Jean-Pierre [mailto:evain@ebu.ch]
> Sent: den 7 februari 2011 11:50
> To: Joakim Söderberg; 'David Singer'
> Cc: tmichel@w3.org MICHEL; 'Bailer, Werner'; 'Tobias Bürger';
> pa@champin.net
> Subject: RE: Recapitulation of ma:format vs. ma:compression.
>
> It's getting worse and worse. Triple sigh!
>
> The point is all "URI only" or all "URI/string".
>
>
> -----Original Message-----
> From: Joakim Söderberg [mailto:joakim.soderberg@ericsson.com]
> Sent: lundi, 7. février 2011 11:47
> To: Evain, Jean-Pierre; 'David Singer'
> Cc: tmichel@w3.org MICHEL; 'Bailer, Werner'; 'Tobias Bürger';
> pa@champin.net
> Subject: RE: Recapitulation of ma:format vs. ma:compression.
>
> Yeah, let me think about it. Perhaps we should divide/or mark the
> attributes in "computer readable" and "human readable" compatible? That
> would be compliant for the future of linked data and automatic metadata
> mashup's.
>
> -----Original Message-----
> From: Evain, Jean-Pierre [mailto:evain@ebu.ch]
> Sent: den 6 februari 2011 10:33
> To: Evain, Jean-Pierre; Joakim Söderberg; 'David Singer'
> Cc: tmichel@w3.org MICHEL; 'Bailer, Werner'; 'Tobias Bürger';
> pa@champin.net
> Subject: RE : Recapitulation of ma:format vs. ma:compression.
>
> After all, maybe another point of clarification as Joakim mail seems to
> mean that the issue is still not understood (??!!??)...
>
> If we follow a strict RDF logic all elements of a triple must be
> dereferencable.
>
> The original Ontology on all occasions considers string as an option
> for objects like language, compression, relation, publisher, genre,
> keyword, sometimes with a URI alternative, sometimes not.  When it
> wasn't I asked to add it.
>
> Now, following the logic to the extreme and this is what would imply
> from David to have a URI only for compression (when I believe I could
> survive with string because many RDF developers may not have the
> resources to populate URIs and I guesss this is the position of many
> MAWG members who originally asked for text as a value)...
>
> if we agree with the change of URI only for compression then I'll ask
> to be consistent and remove all 'string' value occurrences from the
> doublons URI/string.
>
> Ready for this Joakim. As a chairman you decide??
>
> Jean-Pierre
>
> ________________________________________
> De : Evain, Jean-Pierre
> Date d'envoi : dimanche, 6. février 2011 09:33
> À : Joakim Söderberg; 'David Singer'
> Cc : tmichel@w3.org MICHEL; 'Bailer, Werner'; 'Tobias Bürger';
> pa@champin.net
> Objet : RE : Recapitulation of ma:format vs. ma:compression.
>
> Dear Joakim,
>
> I did a long time ago.
>
> Jean-Pierre
> ________________________________________
> De : Joakim Söderberg [joakim.soderberg@ericsson.com]
> Date d'envoi : dimanche, 6. février 2011 03:01
> À : Evain, Jean-Pierre; 'David Singer'
> Cc : tmichel@w3.org MICHEL; 'Bailer, Werner'; 'Tobias Bürger';
> pa@champin.net
> Objet : RE: Recapitulation of ma:format vs. ma:compression.
>
> Dear Jean-Pierre,
> I respect your expertise and contributions; can you come up with a
> constructive proposal to the problem?
>
> /Joakim
>
> -----Original Message-----
> From: Evain, Jean-Pierre [mailto:evain@ebu.ch]
> Sent: den 3 februari 2011 21:54
> To: 'David Singer'
> Cc: tmichel@w3.org MICHEL; Joakim Söderberg; 'Bailer, Werner'; 'Tobias
> Bürger'; pa@champin.net
> Subject: RE: Recapitulation of ma:format vs. ma:compression.
>
> In the context of our discussion I only referred to string if
> associated to URI as an alternative value. Other strings are of course
> not relevant in this context.
>
> About the use of string/URI, which were originally string only from
> http://www.w3.org/TR/2010/WD-mediaont-10-20100608/ and which I asked to
> change:
>
> Language,
> targetAudience.Classification,
> Compression
>
> Like in publisher -> it is recommended to use a URI but string wasn't
> removed!! Including for genre, rating, etc.
>
> Of course roles of the contributors should also potentially be URI or
> string (there are classification schemes for roles but we have solved
> this in the RDF by using properties extendable at will.
>
> Other comments:
> - target audience is about parental control and the geographical or
> group of persons targeted
> - rating is a value given by a user to the content and the fact that
> URI/string only allows to identify the rating scheme is right
>
> For compression, my view is that content should be in a format that is
> compliant with what most popular player can deal with and be auto
> detected. But in case it would be confused with format I prefer to have
> it by default.
>
> Dates have format date in the RDF.
>
>
> -----Original Message-----
> From: David Singer [mailto:singer@apple.com]
> Sent: jeudi, 3. février 2011 21:20
> To: Evain, Jean-Pierre
> Cc: tmichel@w3.org MICHEL; Joakim Söderberg; 'Bailer, Werner'; 'Tobias
> Bürger'; pa@champin.net
> Subject: Re: Recapitulation of ma:format vs. ma:compression.
>
> OK, Jean-Pierre
>
> you and I seem to be in agreement that if you want an interoperable
> name, you need syntax and semantics.  I am not 'attacking' you, I am
> looking for a good spec., and as I said, your input has been helpful.
> I was asked to provide improved text, I did that, you refined it, and
> it apparently achieved consensus (though it may be that people didn't
> read it -- I cannot tell), and then I got the report that the edits had
> been made, when in fact they had not. That's what made me ask "what is
> going on?".
>
>
> You mention "String" is used in other places.  But for the majority of
> uses, it's for human-readable text, not a property you'd want to
> machine-match or inspect, and so interoperability of the value-space is
> not a concern, and an undefined string is right:
>   contributor name
>   title
>   creator
>   location (but it allows specifying the coordinate system)
>   description
>   keyword
>   relation
>   collection name
>   copyright
>   policy
>   publisher
>   targetAudience (though it's not clear to me how this differs from
> rating, mind you)
>   fragment role
>   fragment name
>   track type
>
> Then there is one that defines the format of the string precisely:
>   format (says that the string is a MIME type)
>
> The following are more problematic, and some improvement of language
> may be beneficial, as machine-inspection and matching might make sense:
>   language (only recommends a controlled vocabulary but doesn't say how
> I can tell if it's used)
>   date (says nothing at all about the format, calendar, or anything, so
> this makes it solely user-presentable right now)
>   genre (only recommends a URI using a controlled vocabulary)
>   rating (only recommends identifying the rating system)
>   frameSize units (no values for the units are given;  are pixels
> "pixel", "pixels", "px", and so on, and are these square or not?)
>
> and then we come to compression.  I rather had assumed that this is not
> a user-presented property of the content (like title, contributor name
> etc.) but rather an ephemeral machine-readable property of this current
> incarnation.  As such, it belongs in there with format, with a well-
> defined value space.  I cannot think of any end-user who wants to know
> "the content you are watching this evening was compressed with MPEG-4
> Advanced Simple Profile at Level 3.3 and AAC-LC enhanced with SBR and
> PS".
>
> So, I think that what we have been discussing, and proposing, makes
> sense.  Make compression into a property with a well-defined format, so
> that it can achieve interoperability.  Or, alternatively, document as a
> user-presented property like a title or person's name.
>
> I don't think it works to try to do both in one property, and, as we
> have explored rather endlessly, it doesn't work to have a machine-
> readable property with no defined syntax or semantics.
>
>
>
> On Feb 3, 2011, at 11:41 , Evain, Jean-Pierre wrote:
>
> > I guess that if people had noted you wanted to remove 'string' as a
> possible value for compression there would have been more reactions.
> >
> > This was the original choice of MAWG and ""I"" brought URI in because
> (again and again and again, so boring) I have well organised resources
> like classification schemes and can use URIs. Not the case of many.
> >
> > You provide a text, I and probably others hadn't seen you had removed
> string or I wouldn't have approved it which was reflected in all my
> mails saying 'no need to change, only to provide an example'
> >
> > Therefore the situation is that there is no agreement.
> >
> > I do not believe that your inflexibility against string is right.
> Although I don't like it I can see why some implementers may use it but
> it's too long to explain.
>
> Someone needs to explain, alas.  It sticks out in the specification
> like a sore thumb.
>
> >
> > If you want to remove string tell MAWG experts they are stupid to
> want it. I personally prefer more flexibility and support both.
>
> I would prefer they explain.
>
> >
> > The funniest of all is that I half solved the problem and I take the
> hits. If I hadn't fought for compression with a URI, the all ontology
> would be filled with string values without all this noise.
> >
> > Simply ridiculous and stupid.
>
> I would rather not use such words.  I remain puzzled, however, at what
> "String" can possibly usefully mean or convey as a value of this
> property.
>
> Since you and I seem to find URIs helpful, and what I suggested (and
> you refined), OK, perhaps someone else can defend "String" -- or we can
> remove it?
>
> compression
>
> (attName="compression", attValue="URI")
>
> 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.   The indicator is a URI that consists
> of a base part and an anchor, that is, in the form base-part#name. The
> base-part is a URI that 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 for some container files, the format parameter can also carry
> an extended MIME type to document this; see [RFC 4281] for one such
> instance.
>
> Examples:
> compression="urn:example-org:codingnames2010#ITU-H264"
> compression="http://example.net/012011/standards/codecs.htm#G711"
> 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).
>
>
> >
> > -----Original Message-----
> > From: David Singer [mailto:singer@apple.com]
> > Sent: jeudi, 3. février 2011 20:25
> > To: Evain, Jean-Pierre
> > Cc: tmichel@w3.org MICHEL; Joakim Söderberg
> > Subject: Re: Recapitulation of ma:format vs. ma:compression.
> >
> >
> > On Feb 3, 2011, at 11:11 , Evain, Jean-Pierre wrote:
> >
> >> Ok Dave,
> >>
> >> now you listen to me very carefully and stop playing the offended
> virgin.
> >
> > Please, you have used inflammatory language before, and I would
> request that you stop using it now.
> >
> >>
> >> If I hadn't required to have URI as a possible value their would be
> only string!!! String was the original choice of MAWG!!!   And
> compression is only one of the many attributes for which I requested a
> URI.
> >
> > Thank you, that was a good move.  I also questioned "string" back
> then.
> >
> >>
> >> You should rather thank me for having an URI. Your 'what's going on
> here' has no effect on me. Your remarks is actually insulting a
> majority of the MAWG members but not me as I asked for URI as one of
> the possible values.
> >
> > Thank you.
> >
> >>
> >> You should also rather thank me for correcting  your proposal and
> putting it on track with the # syntax and pointing out that the value
> couldn't be URI#Name but simply a URI.
> >
> > I do thank you.  Changing "," to "#" was an improvement.
> >
> >>
> >> Therefore, STOP now giving lessons or at least provide good syntaxes
> and show your knowledge of the URI syntax.
> >
> > OK.  I can quote chapter and verse of the URI specifications, but
> isn't that kinda overboard?
> >
> >>
> >> Again, even if it not best practice, I suspect there will be value
> given as strings as members of MAWG originally asked for it!!!
> >
> > But no-one, precisely no-one is able to tell us how anyone achieves
> any useful effect or interoperability with a string.  That is the basic
> problem.  You and I seem to understand that URIs give a clear,
> interoperable, non-conflicting, non-registered namespace.
> >
> >>
> >> I won't repeat this ten times but for me string is a matter of
> legacy, I prefer URI because I have well published classification
> schemes. but other in MAWG think differently. But please don't hesitate
> to tell them they are stupid. Be my guest.
> >
> > I'm not telling them they are stupid.  I am *asking* how they achieve
> interoperability, non-collision, and so on.  And so far, alas, I am
> getting silence.
> >
> >>
> >> You come at the last minute, find something to chew and impose your
> views. Your problem, not mine. Just beware that you may be losing more
> than you would win by continuing this debate.
> >
> > I am trying to achieve an interoperable specification.  I have
> struggled in other places with the lack of uniform codec naming.
> >
> > So, please.  I provided text, we had agreement, and then it's not
> implemented.  Can someone explain why?
> >
> > There may well be other parts of the spec. that have this problem.
> Perhaps we should, indeed, fix them all.  But perhaps someone can
> explain what I am missing, that having a "string" value is useful here.
> >
> >
> >>
> >> Jean-Pierre
> >>
> >> ________________________________________
> >> De : David Singer [singer@apple.com]
> >> Date d'envoi : jeudi, 3. février 2011 19:15
> >> À : Evain, Jean-Pierre
> >> Cc : 'tmichel@w3.org'
> >> Objet : Re: RE : RE : RE : Recapitulation of ma:format vs.
> ma:compression.
> >>
> >> sigh.
> >>
> >> but that is what I was objecting to in the first place.  once you
> allow undifferentiated strings with no required syntax or semantics,
> you have no interoperability.  someone can even use a completely
> misleading URI -- which is, after all, a string -- and say that they
> only meant it to be a string!
> >>
> >> I thought we had agreement.
> >>
> >> What is going on here?  I provided detailed text for which there was
> only one complaint (that URI#name is still a URI), which I have fixed.
> >>
> >>
> >> On Feb 3, 2011, at 9:14 , Evain, Jean-Pierre wrote:
> >>
> >>> I would just recommend we keep URI or string as values as this is
> how we do it for all similar cases-
> >>>
> >>> I know it not best practice but some would just give a string
> value.
> >>>
> >>> Best regards, Jean-Pierre
> >>>
> >>> ________________________________________
> >>> De : David Singer [singer@apple.com]
> >>> Date d'envoi : jeudi, 3. février 2011 17:48
> >>> À : Evain, Jean-Pierre
> >>> Cc : 'tmichel@w3.org'
> >>> Objet : Re: RE : RE : Recapitulation of ma:format vs.
> ma:compression.
> >>>
> >>> There is indeed agreement.
> >>>
> >>> There is the syntax and semantics agreed to, but as JP says,
> URI#Name *is* a URI.  So see below for a slight re-formulation, which
> avoids this problem:
> >>>
> >>> Originally agreed:
> >>>
> >>> * * * *
> >>>
> >>> compression
> >>>
> >>> (attName="compression", attValue="URI#Name")
> >>>
> >>> 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.   The indicator is a pair of values,
> separated by a hash sign ("#"). The first is a URI that 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 for some container files, the format parameter can also
> carry an extended MIME type to document this; see [RFC 4281] for one
> such instance.
> >>>
> >>> Examples:
> >>> compression="urn:example-org:codingnames2010#ITU-H264"
> >>> compression="http://example.net/012011/standards/codecs.htm#G711"
> >>> 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).
> >>>
> >>> * * * * * * *
> >>>
> >>> Revised:
> >>>
> >>> compression
> >>>
> >>> (attName="compression", attValue="URI")
> >>>
> >>> 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.   The indicator is a URI that consists
> of a base part and an anchor, that is, in the form base-part#name. The
> base-part is a URI that 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 for some container files, the format parameter can also
> carry an extended MIME type to document this; see [RFC 4281] for one
> such instance.
> >>>
> >>> Examples:
> >>> compression="urn:example-org:codingnames2010#ITU-H264"
> >>> compression="http://example.net/012011/standards/codecs.htm#G711"
> >>> 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).
> >>>
> >>> * * * *
> >>>
> >>> I don't care about including the examples;  I am looking for
> interoperable syntax and semantics.  You took only the examples in the
> edit you did, which is useless.
> >>>
> >>>
> >>> Thanks
> >>>
> >>>
> >>> On Feb 3, 2011, at 0:33 , Evain, Jean-Pierre wrote:
> >>>
> >>>> Thierry,
> >>>>
> >>>> But there is an agreement. Dave and me have been meeting in Korea.
> I suggested that he replaces the coma in his proposal with a # for
> URI#Name. Then you can have the text of the example he wrote in the
> semantics of the compression attribute. However, the definition
> URI/string doesn't need to be changed because URI#Name is a URI.
> >>>>
> >>>> I agreed to have the example if it helped Dave feel more
> comfortable but the RDF and the ontology accordingly have been designed
> from the beginning to identify e.g. compression codec using the URI#ID
> to point e.g. at SKOS concepts or other mpeg-7/DVB/EBU like termID in
> Classification Schemes.  This is why the definition is just right and
> all we need is the example in the semantics.
> >>>>
> >>>> Easy.
> >>>>
> >>>> Jean-Pierre
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Thierry MICHEL [mailto:tmichel@w3.org]
> >>>> Sent: jeudi, 3. février 2011 09:28
> >>>> To: Evain, Jean-Pierre; singer@apple.com >> Dave Singer
> >>>> Subject: Re: RE : RE : Recapitulation of ma:format vs.
> ma:compression.
> >>>>
> >>>> Jean Pierre,
> >>>>
> >>>> Please, can you and David come up to an agreement on this small
> issue.
> >>>>
> >>>> thierry
> >>>>
> >>>> Le 03/02/2011 09:14, Evain, Jean-Pierre a écrit :
> >>>>> It is not wrong but it is not elegant. URI#Name is a URI. The
> original definition was right. As I said no need for modification. Only
> add the example in the semantics.
> >>>>>
> >>>>> Jean-Pierre
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Thierry MICHEL [mailto:tmichel@w3.org]
> >>>>> Sent: jeudi, 3. février 2011 09:09
> >>>>> To: Evain, Jean-Pierre
> >>>>> Cc: David Singer; Joakim Söderberg; Daniel Park; public-media-
> annotation@w3.org
> >>>>> Subject: Re: RE : RE : Recapitulation of ma:format vs.
> ma:compression.
> >>>>>
> >>>>> Updated to:
> >>>>>
> >>>>> compression  (attName="compression", attValue="URI#Name" |
> "String")
> >>>>>
> >>>>> see
> >>>>> http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-
> 1.0.html#core-property-lists
> >>>>>
> >>>>>
> >>>>> Thierry
> >>>>>
> >>>>>
> >>>>>
> >>>>> Le 31/01/2011 07:28, Evain, Jean-Pierre a écrit :
> >>>>>> Hi David,
> >>>>>>
> >>>>>> I see you had a safe trip back. Me too but I arrived quite late
> in Geneva with Touradj.
> >>>>>>
> >>>>>> As discussed, fine by me as # constructs are URI and is directly
> compatible with the way the ontology has been written.
> >>>>>>
> >>>>>> However only one additional comment: I would suggest we
> recommend the use of ea dereferencable URIs, which use a URL basis
> instead of namespaces.  For example, EBU Skos classification schemes
> are available as permanent web resources and use URL based URIs.
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Jean-Pierre
> >>>>>> ________________________________________
> >>>>>> De : public-media-annotation-request@w3.org [public-media-
> annotation-request@w3.org] de la part de David Singer
> [singer@apple.com]
> >>>>>> Date d'envoi : samedi, 29. janvier 2011 23:26
> >>>>>> À : tmichel@w3.org
> >>>>>> Cc : Joakim Söderberg; Daniel Park; public-media-
> annotation@w3.org
> >>>>>> Objet : Re: RE : Recapitulation of ma:format vs. ma:compression.
> >>>>>>
> >>>>>> In further discussion, it seems that using anchor syntax and a #
> as the separator is cleaner.  Can we change to
> >>>>>>
> >>>>>>>> attValue="URI#Name"
> >>>>>>
> >>>>>>>>   compression="urn:example-org:codingnames2010#ITU-H264"
> >>>>>>>>   compression="http://example.net/standards/codecs#G711"
> >>>>>>
> >>>>>> with corresponding changes to the text?
> >>>>>>
> >>>>>> On Jan 29, 2011, at 23:28 , Thierry MICHEL wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>> compression
> >>>>>>>>
> >>>>>>>> (attName="compression", attValue="URI" | "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. Note:
> it is possible to use an extendedMIME type as the value for this
> property, see [RFC 4281].
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> suggested change to
> >>>>>>>>
> >>>>>>>> compression
> >>>>>>>>
> >>>>>>>> (attName="compression", attValue="URI, 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.   The
> indicator is a pair of values, separated by a comma. The first is a URI
> that identifies the naming convention used for the second parameter,
> which is a string.  For some container files, the format parameter can
> also carry an extended MIME type to document this; see [RFC 4281] for
> one such instance.
> >>>>>>>>
> >>>>>>>> Examples:
> >>>>>>>>   compression="urn:example-org:codingnames2010, ITU-H264"
> >>>>>>>>   compression="http://example.net/standards/codecs, G711"
> >>>>>>>> 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).
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Updated the compression Statement.
> >>>>>>> http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-
> 1.0.html#core-property-lists
> >>>>>>>
> >>>>>>> For the examples; I have added a link to the following section,
> which contains the examples.
> >>>>>>>
> >>>>>>> 5.1.3.1 Examples for the compression property
> >>>>>>>
> >>>>>>> Best,
> >>>>>>>
> >>>>>>> Thierry
> >>>>>>>
> >>>>>>
> >>>>>> David Singer
> >>>>>> Multimedia and Software Standards, Apple Inc.
> >>>
> >>> David Singer
> >>> Multimedia and Software Standards, Apple Inc.
> >>
> >> David Singer
> >> Multimedia and Software Standards, Apple Inc.
> >
> > David Singer
> > Multimedia and Software Standards, Apple Inc.
> >
> > -----------------------------------------
> > **************************************************
> > This email and any files transmitted with it
> > are confidential and intended solely for the
> > use of the individual or entity to whom they
> > are addressed.
> > If you have received this email in error,
> > please notify the system manager.
> > This footnote also confirms that this email
> > message has been swept by the mailgateway
> > **************************************************
> >
>
> David Singer
> Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 8 February 2011 09:30:09 UTC