Clarify terminology #49

chrisn · 2019-06-03T12:52:06Z

This PR clarifies the terminology used in the document:

"Timed metadata" is a generally accepted term, so we use this in place of "media timed events" where appropriate
Replace "JavaScript event" with the more accurate "DOM event"
Other uses of "event" are either qualified or should be more obvious from context (e.g,. DASH MPD and emsg events)

mavgit · 2019-06-04T21:44:43Z

I suggest also changing the name of the document, since a title with the industry term "Timed Metadata" (or "Timed Metadata Requirements" or "Requirements for Timed Metadata") will draw more readers than "Media Timed Events"

nigelmegitt · 2019-06-05T08:56:27Z

Sorry, -1 to that idea @mavgit , timed media events such as subtitle (cue) changes are clearly in scope, and I feel so strongly about this that I'd actually object to referring to those as metadata.

chrisn · 2019-06-05T09:11:02Z

Yes, the scope here is broader than DataCue (the proposed API for timed metadata), and DataCue can be used for things that are more event notifications than metadata (e.g., the MPEG-DASH MPD validity expiration event).

Feedback on the proposed changes in this PR is welcome.

tidoust

One thing that seems missing right now is the link between timed metadata and cues. The document defines cues in 5.2.1 "Cues (e.g., TextTrackCue , or VTTCue ) are units of time-sensitive data on a media timeline [ HTML ]" but without reference to timed metadata.

AFAICT, the two terms appear in combination for the first time in 6.1 "The API should allow web applications to subscribe to receive specific timed metadata cues by schema".

I would suggest to:

move the definition of cues from 5.2.1 to the terminology section;
clarify that timed metadata typically get exposed as a set of cues in the definition of timed metadata;
and, for extra bonus points, link back occurrences of "cues" to the definition

tidoust · 2019-06-05T10:06:40Z

index.html

+        Timed metadata may be carried either "in-band", meaning that they are
+        delivered within the audio or video media container or multiplexed with
+        the media stream, or "out-of-band", meaning that they are delivered
+        externally to the media container or media stream.


I suggest to drop quotes around "in-band" and "out-of-band" and to wrap them in <a> instead to link back to the definition of these terms in this document.

tidoust · 2019-06-05T10:11:32Z

index.html

-        from JavaScript events, at specific points on the <a>media timeline</a>
-        of an audio or video media stream.
+        There is a need in the media industry for an API to support timed
+        metadata, i.e., metadata that is synchronized to audio or video media,


Wrap "timed metadata" in <a> to link back to the definition of the term?

(The document repeats the definition of this term and of "in-band" and "out-of-band" in practice but that seems fine to repeat the definition in the introduction)

mavgit · 2019-06-05T21:12:00Z

@nigelmegitt & @chrisn , I'm not trying to argue for or against the phrase "timed metadata". I'm really making an editorial comment about being consistent with PR #49.

After PR #49 is applied:

There are now 31 references to the new phrase "timed metadata", while only 2 remain of "media timed events" (in the title and in section 4.6).
"timed metadata" is defined twice, in Section 1 & 2, while "media timed events" is completely undefined, even in the context of the one usage in 4.6.
The document summary in Section 1. Introduction is now all about "timed metadata".

So, my point is that it makes no sense to title the document with a phrase which is undefined, unused in the document (save once) and unmentioned in the summary introduction.

Now, if there's a better replacement for "timed metadata", that's a different, perfectly reasonable discussion. I just don't see the point of keeping the doc named with a phrase that has been essentially eliminated from the doc in PR #49.

- Add 'cue' to Terminology section - Replace remaining uses of 'media timed events' - Renamed headings under Recommendations

nigelmegitt

Some minor editorial comments and a bigger question about payload type signalling.

index.html

nigelmegitt · 2019-06-10T09:55:46Z

index.html

+          timeline</a>, to be triggered by the user agent. The API should allow
+          the web application to provide all necessary parameters to define the
+          cue, including start and end times, schema identifier, and data
+          payload. The payload should be any data type (e.g., the set of types


Do we need to say anything about payload type signalling?

Is this covered by "schema identifier"?

Not obviously - that sounds like it's something that would help to parse the payload data of the cue, not to select it.

suggest s/schema identifier/schema identifier, type identifier

The latest update has "cue type identifier", in both the "Subscribing to receive media timed event cues" and "Out-of-band events" sections.

nigelmegitt

This change introduces the idea of a "metadata cue" but all the concepts it refers to are more general than metadata, and do even include control data. I don't think control data can ever be considered to be metadata. Also, one of the proposals for resolving this is called DataCue.

On balance, I think we should use the term "data cue" instead. Apart from that, the changes look good to me.

index.html

nigelmegitt

Responding to questions about payload type signalling - in my view it is not the same as schema identification. Actually the type identification should be less optional than the schema identification.

nigelmegitt · 2019-07-11T09:06:36Z

index.html

        <p>
          The API should allow web applications to subscribe to receive specific
-          event streams by event type. For example, to support MPEG-DASH
+          schemas of <a>timed metadata</a> cue. For example, to support MPEG-DASH


suggest s/schemas/types to be more general. Schema can be taken as a data type definition not something against which to select content.

a33e48b replaces "schema" with "cue type"

nigelmegitt · 2019-07-11T09:07:44Z

index.html

-          agent should deliver only those events to a web application for which
-          the application has subscribed. The API should also allow web
-          applications to unsubscribe from specific event streams by event type.
+          receiving the cues opt-in from the application's point of view. The


s/the cues/cues grouped by type

Resolved in a33e48b

nigelmegitt · 2019-07-11T09:09:32Z

index.html

+          timeline</a>, to be triggered by the user agent. The API should allow
+          the web application to provide all necessary parameters to define the
+          cue, including start and end times, schema identifier, and data
+          payload. The payload should be any data type (e.g., the set of types


Not obviously - that sounds like it's something that would help to parse the payload data of the cue, not to select it.

nigelmegitt · 2019-07-11T09:10:00Z

index.html

+          timeline</a>, to be triggered by the user agent. The API should allow
+          the web application to provide all necessary parameters to define the
+          cue, including start and end times, schema identifier, and data
+          payload. The payload should be any data type (e.g., the set of types


suggest s/schema identifier/schema identifier, type identifier

chrisn · 2019-07-11T09:25:03Z

The use of timed metadata as a term seems well established elsewhere, so I was trying to be consistent with that. I agree it's not a great fit for things that are really control messages though - I note that the DASH-IF document talks about "events and timed metadata".

This avoids describing the DASH specific control messages as timed metadata.

nigelmegitt · 2019-07-15T09:37:43Z

Sorry, I've confused myself with GitHub here and approved a smaller set of changes, only to see afterwards that it approved the whole pull request, and I don't have the opportunity to dismiss my own review! I would like my previous review comments to be addressed, ideally.

chrisn · 2020-01-17T15:27:59Z

In the latest update I have gone back to using the previous "media timed event" terminology, and added text to the introduction to explain that this encompasses timed metadata and timed control messages.

This should address @mavgit's observation that the terminolgy in the document doesn't match the title.

Other uses of "event" are either qualified or should be more obvious from context (e.g,. DASH MPD and emsg events, and DOM events)

I think this PR is ready to merge. PTAL @cconcolato, @rjksmith, @nigelmegitt.

chrisn · 2020-02-10T14:45:05Z

I'll merge this PR, and we can raise further issues to address specific points, as needed.

Clarify terminology

8bc7852

See #41

tidoust reviewed Jun 5, 2019

View reviewed changes

Clarify terminology

7d1428c

- Add 'cue' to Terminology section - Replace remaining uses of 'media timed events' - Renamed headings under Recommendations

chrisn force-pushed the terminology branch from 4bd6072 to 7d1428c Compare June 7, 2019 14:24

nigelmegitt reviewed Jun 10, 2019

View reviewed changes

chrisn and others added 2 commits June 10, 2019 15:27

Replace 'region' with 'period'

95ea7a7

Merge branch 'master' into terminology

31f055a

nigelmegitt reviewed Jul 11, 2019

View reviewed changes

index.html Outdated Show resolved Hide resolved

index.html Outdated Show resolved Hide resolved

index.html Outdated Show resolved Hide resolved

nigelmegitt reviewed Jul 11, 2019

View reviewed changes

chrisn added 3 commits July 12, 2019 11:31

Merge branch 'master' into terminology

34243b7

Reword Control messages section

35e7d08

This avoids describing the DASH specific control messages as timed metadata.

Merge remote-tracking branch 'origin/terminology' into terminology

dfbe1e2

nigelmegitt approved these changes Jul 15, 2019

View reviewed changes

chrisn added 7 commits July 15, 2019 18:58

Replace 'schema' with 'cue type'

a33e48b

Improve timed metadata definition

e8507b7

Merge branch 'master' into terminology

c565f96

Reword Introduction

4fed96e

Revert to use previous "media timed events" terminology

028676e

Update terminology in Abstract

2c275ef

Clarify time marches on behaviour

5bdacf3

chrisn mentioned this pull request Jan 17, 2020

event is not defined #41

Closed

chrisn merged commit 3baeaf4 into master Feb 10, 2020

chrisn deleted the terminology branch February 10, 2020 14:45

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clarify terminology #49

Clarify terminology #49

chrisn commented Jun 3, 2019 •

edited by pr-preview bot

Loading

mavgit commented Jun 4, 2019

nigelmegitt commented Jun 5, 2019

chrisn commented Jun 5, 2019

tidoust left a comment

tidoust Jun 5, 2019

chrisn Jun 7, 2019

tidoust Jun 5, 2019

chrisn Jun 7, 2019

mavgit commented Jun 5, 2019

nigelmegitt left a comment

nigelmegitt Jun 10, 2019

chrisn Jun 10, 2019

nigelmegitt Jul 11, 2019

nigelmegitt Jul 11, 2019

chrisn Jan 6, 2020

nigelmegitt left a comment

nigelmegitt left a comment

nigelmegitt Jul 11, 2019

chrisn Jul 15, 2019

nigelmegitt Jul 11, 2019

chrisn Jul 15, 2019

nigelmegitt Jul 11, 2019

nigelmegitt Jul 11, 2019

chrisn commented Jul 11, 2019

nigelmegitt commented Jul 15, 2019

chrisn commented Jan 17, 2020

chrisn commented Feb 10, 2020

Clarify terminology #49

Clarify terminology #49

Conversation

chrisn commented Jun 3, 2019 • edited by pr-preview bot Loading

mavgit commented Jun 4, 2019

nigelmegitt commented Jun 5, 2019

chrisn commented Jun 5, 2019

tidoust left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mavgit commented Jun 5, 2019

nigelmegitt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nigelmegitt left a comment

Choose a reason for hiding this comment

nigelmegitt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chrisn commented Jul 11, 2019

nigelmegitt commented Jul 15, 2019

chrisn commented Jan 17, 2020

chrisn commented Feb 10, 2020

chrisn commented Jun 3, 2019 •

edited by pr-preview bot

Loading