Re: Track kinds

Hi Silvia,

I like your proposed reply, except this last part.

On Jun 5, 2011, at 10:34 PM, Silvia Pfeiffer wrote:

There will be no URN to specify these names.

Specifying a URN is no more than giving a permanent machine-readable name to the list of values (not, it's not a URN for each individual value). It has not cost (URNs are an infinite resource) and has value in that it enables the kinds we specify to be referred to in other protocols, specifically DASH.


We recommend that the 3GPP define their own names, since they may
require more than what HTML5 requires. We therefore further recommend
that 3GPP create a URN scheme for their own names themselves.

3GPP certainly can and will do the above if they have requirements not met by the W3C kinds. But it would be better to avoid the situation were we have duplicate definitions in HTML and container formats and the consequent maintenance problem ...

There
will be no URN for the W3C names, since they are listed in the HTML5
specification and will be maintained there.

I didn't follow the logic of that last sentence.

I think that container specifications are absolutely the wrong place for these definitions as there is nothing container-specific about the concept of track kinds. The right place is somewhere that abstracts the services offered by multiple different containers and offers them to the higher application layers in a container-independent language - which is what HTML does.

3GPP and MPEG are offering to support that container-independent language directly. It would be a great benefit if we took them on that offer and gave them a way to refer to our list. (That doesn't mean there won't be other lists defined in other places for particular applications).

...Mark