*** Bug 24567 has been marked as a duplicate of this bug. ***

This would go into the mime type registration which is currently in section 8.1. I'do go with the Media Fragment URI spec: http://www.w3.org/TR/2012/PR-media-frags-20120315/#fragment-dimensions . I'd include the temporal and the id referencing mechanisms: #t= and #id= where the first one would reference a list of cues that fall into the given time range, while the second is a reference to the first (all?) cues with the given identifier.

Seeing as we should do an IANA registration, does it make sense to move this to v1?

I don't understand this bug. The text track is synced with the media resource's timeline, what would a fragment on the text track URL actually do?

@Philip For me, the idea was not so much to *do* anything, but to be able to *talk* about a given cue from outside the Web-VTT file, so provide each (identified) cue with a full URI.

@Sylvia I like very much the idea to reuse media-fragment in this context!

(In reply to Pierre-Antoine Champin from comment #4)
> @Philip For me, the idea was not so much to *do* anything, but to be able to
> *talk* about a given cue from outside the Web-VTT file, so provide each
> (identified) cue with a full URI.

Can you elaborate a bit on what you'd like to do? It seems to me that if such a URI shouldn't cause any software to do anything, it doesn't need to be standardized. The most straightforward way of identifying a cue would seem to be using just the id in a context where the file URL is known and not bothering with global identifiers...

(In reply to Philip Jägenstedt from comment #5)
> Can you elaborate a bit on what you'd like to do? It seems to me that if
> such a URI shouldn't cause any software to do anything, it doesn't need to
> be standardized.

A use case that I have in mind would be to use RDF to say something about (annotate) an individual cue. E.g.:

- the text of this cue contains an error / a typo
- this cue has incorrect timestamps
- this cue is uttered by that person (URI of the person)

Of course, systems will *do* something with those annotations, my point was only that I'm not making any assumptions on those various actions.
However, to make them possible To do that, I need a full URI to identify the fragment, whose semantics is standardized in order to be unambiguous.

> The most straightforward way of identifying a cue would
> seem to be using just the id in a context where the file URL is known and
> not bothering with global identifiers...

Well prefixing the cue ID with the file URL and a hash is not *that* bothering, and it is a straightforward way to make that context explicit.

(In reply to Pierre-Antoine Champin from comment #6)
> (In reply to Philip Jägenstedt from comment #5)
> > Can you elaborate a bit on what you'd like to do? It seems to me that if
> > such a URI shouldn't cause any software to do anything, it doesn't need to
> > be standardized.
> 
> A use case that I have in mind would be to use RDF to say something about
> (annotate) an individual cue. E.g.:
> 
> - the text of this cue contains an error / a typo
> - this cue has incorrect timestamps
> - this cue is uttered by that person (URI of the person)
> 
> Of course, systems will *do* something with those annotations, my point was
> only that I'm not making any assumptions on those various actions.
> However, to make them possible To do that, I need a full URI to identify the
> fragment, whose semantics is standardized in order to be unambiguous.

These use cases sound rather hypothetical at this point, assuming you're not currently building a collaborative editing system for WebVTT. I think that in order to build a collaborative such a system which is robust, you cannot depend on IDs at all, as they may be missing or duplicated. A more robust approach would be to have a custom format that's a superset of the WebVTT model. Otherwise I don't see how you're going to keep the extra data when cues are added/removed or the IDs are changed.

Unless implementations (browsers or standalone players) of WebVTT have some testable behavior for media fragments in <track src="file.vtt#id=foo"> I don't think we should add anything to the spec, i.e. I would prefer to WONTFIX this.

Silvia?

(In reply to Philip Jägenstedt from comment #7)
> > Of course, systems will *do* something with those annotations, my point was
> > only that I'm not making any assumptions on those various actions.
> > However, to make them possible To do that, I need a full URI to identify the
> > fragment, whose semantics is standardized in order to be unambiguous.
> 
> These use cases sound rather hypothetical at this point, assuming you're not
> currently building a collaborative editing system for WebVTT. 

That's actually the kind of thing that we are aiming to do :)

> I think that
> in order to build a collaborative such a system which is robust, you cannot
> depend on IDs at all, as they may be missing or duplicated.

would it be valid Web-VTT if there was a duplicate identifier??
If yes, then indeed they are bad candidates for fragments ids,
but then they should probably *not* be named "identifiers" in the first place!
If not, then I insist there should be a way to use them in a context-free way, see below... 

> (...)
> Unless implementations (browsers or standalone players) of WebVTT have some
> testable behavior for media fragments in <track src="file.vtt#id=foo"> I
> don't think we should add anything to the spec, i.e. I would prefer to
> WONTFIX this.

I understand your position regarding the testability of what is in the spec.
On the other hand, RFC3986 says

> The semantics of a fragment identifier are defined by the set of
> representations that might result from a retrieval action on the
> primary resource.  The fragment's format and resolution is therefore
> dependent on the media type [RFC2046] of a potentially retrieved
> representation.

So by *not* specifying it, you close the door once and for all to any kind of cue addressing.
On the other hand, by allowing fragments identifiers, and specifying only what they *mean* (rather than what behaviour this implies in such or such application), you leave the door open to extensibility.

(In reply to Pierre-Antoine Champin from comment #8)
> (In reply to Philip Jägenstedt from comment #7)
> 
> > I think that
> > in order to build a collaborative such a system which is robust, you cannot
> > depend on IDs at all, as they may be missing or duplicated.
> 
> would it be valid Web-VTT if there was a duplicate identifier??
> If yes, then indeed they are bad candidates for fragments ids,
> but then they should probably *not* be named "identifiers" in the first
> place!
> If not, then I insist there should be a way to use them in a context-free
> way, see below... 

You can depend on IDs in WebVTT files as much as you can in HTML files. They are supposed to be unique, but author mistakes will be tolerated - URLs would then just resolve to the first one and duplicates can't be addresses (just like in HTML).


> > Unless implementations (browsers or standalone players) of WebVTT have some
> > testable behavior for media fragments in <track src="file.vtt#id=foo"> I
> > don't think we should add anything to the spec, i.e. I would prefer to
> > WONTFIX this.

I can imagine a situation with a very long video where you want to just retrieve a subpart of the video's timeline and the related subpart of the vtt files:

<video src="video.webm#t=npt:2:50:00,2:55:00">
  <track src="captions.vtt#t=npt:2:50:00,2:55:00">
</video>

That would allow to use a reduced size video and skip to the right cues in the vtt file.

Though I agree that this is a pretty convoluted and unrealistic example, since you'd probably rather use a query parameter on the vtt file to have the server send a reduced size vtt file. (I assume byte range requests wouldn't be done on the vtt file no matter how large).


> I understand your position regarding the testability of what is in the spec.
> On the other hand, RFC3986 says
> 
> > The semantics of a fragment identifier are defined by the set of
> > representations that might result from a retrieval action on the
> > primary resource.  The fragment's format and resolution is therefore
> > dependent on the media type [RFC2046] of a potentially retrieved
> > representation.
> 
> So by *not* specifying it, you close the door once and for all to any kind
> of cue addressing.
> On the other hand, by allowing fragments identifiers, and specifying only
> what they *mean* (rather than what behaviour this implies in such or such
> application), you leave the door open to extensibility.

That's how I was looking at it: merely as an addition to the mime type registration to point people who want to do such URI addressing in the right direction. I can particularly think of annotation and archiving use cases that would want to deal with such things.

I guess we should ask for some more concrete examples and can leave it for now as a v2 feature. This is really only relevant once we register the mime type with IANA.

*** Bug 27326 has been marked as a duplicate of this bug. ***