Review of WebVMT Draft Note

[rjksmith]

WebVMT Editor's Draft has been updated with new features including:

• synchronised data
• interpolation
• altitude
• CSS extensions
• revised API

Development is still ongoing, but I've included the features which are sufficiently mature so that more implementations can be written to help support and strengthen the user community.

My aim is to publish this document as a W3C Note and I'd welcome constructive feedback in the comments here to help complete that process. Many thanks for your time.

Changes are in pull requests w3c/sdw#1373 & w3c/sdw#1396

Please submit comments by 31 March 2023. Thank you.

[chris-little]

1. @rjksmith I suggest that you may want to add the note along the lines of: The Second component cannot be 60 or 61; leap seconds cannot be represented. for the seconds. There is a note to that effect in the HTML valid global time web page. I think this would apply to both the media start time and the cue offsets. I am sure someone, somewhere, will record, or already have recorded, across a leap second or two introduction. Maybe a one or two second discrepancy is acceptable, but at least be explicit about it.

2. Maybe also a note to the effect that only clocks that are stationary w.r.t. to each other can be exactly synchronized. If they are moving w.r.t.each other, accuracy of synchronisation depends on the relative speeds, distances and the number of iterations of the synchronisation messages. (This is not a relativistic thing, it was a railway issue more than a century ago, finally sorted by Poincaré.)

[6a6d74]

@rjksmith - now that the review period has closed @lvdbrink and I are preparing to move to publish the proposal as a W3C NOTE.

On my final read through, I was pleased to see enough options in section 3.5 Interpolation to cover even fernickety folks who don't want to display numbers that they've not actually recorded (i.e., discrete interpolation). For those that do want to see gradually changing values, the linear interpolation should be sufficient - after all, it's only a map rendering control and authors can add more dense sets of cues if the data changing is properly important.

The other thing I had to read twice was in section 6.3 WebVMT Media Setting - I misread media path to infer the path to the media resource (i.e., the URL), but figured out my mistake. It's meant to identify the moving object that recorded the media (or some-such). You don't have any examples using this feature though - might be a nice to add if you're adding any final changes.

@lvdbrink - please update this issue once you've completed your final read through.

@rjksmith - are there any modifications you want to make before we publish (such as implementing the suggestion from Chris Little above).

Good work. Thanks for all your efforts. The result is a clear, well-written spec!

[lvdbrink]

I've completed my read through and agree, it's good work and a clear read!

[rjksmith]

Many thanks for the feedback. I plan to address the issues raised and will confirm when that's complete so we can progress to the next stage early next week.

[6a6d74]

Many thanks for the feedback. I plan to address the issues raised and will confirm when that's complete so we can progress to the next stage early next week.

Thanks @rjksmith ... please would you ping Linda and me directly on email. Then we'll start the NOTE publication.

[rjksmith]

@chris-little Thanks for your feedback and apologies for my delayed response.

1. @rjksmith I suggest that you may want to add the note along the lines of: The Second component cannot be 60 or 61; leap seconds cannot be represented. for the seconds. There is a note to that effect in the HTML valid global time web page. I think this would apply to both the media start time and the cue offsets. I am sure someone, somewhere, will record, or already have recorded, across a leap second or two introduction. Maybe a one or two second discrepancy is acceptable, but at least be explicit about it.

Start and end times of WebVMT cues are properties inherited from text track cue which are time offsets relative to the start of the media timeline, i.e. zero. I believe that these properties are agnostic of leap seconds.

NOTE There are 3 seconds before this cue starts, and 2 more seconds until it ends.

00:00:03.000 --> 00:00:05.000

The WebVMT media start time can be used to calculate the timeline offset property of the media element. This links the media timeline to an explicit date and time, though I believe that the media timeline still remains agnostic of leap seconds.

Do you have a counterexample?

2. Maybe also a note to the effect that only clocks that are stationary w.r.t. to each other can be exactly synchronized. If they are moving w.r.t.each other, accuracy of synchronisation depends on the relative speeds, distances and the number of iterations of the synchronisation messages. (This is not a relativistic thing, it was a railway issue more than a century ago, finally sorted by Poincaré.)

The closest reference I can find to your description is local time which is associated with special relativity.

 t' = t + vx/c^2

However, you mentioned that this is not relativistic, so I'm unclear whether I've understood correctly. Please confirm details of the synchronisation issue (or a suitable link) and how this would affect WebVMT. Note that WebVMT timestamps are only accurate to the nearest millisecond.

[rjksmith]

@6a6d74 Thanks for your comments.

The other thing I had to read twice was in section 6.3 WebVMT Media Setting - I misread media path to infer the path to the media resource (i.e., the URL), but figured out my mistake. It's meant to identify the moving object that recorded the media (or some-such). You don't have any examples using this feature though - might be a nice to add if you're adding any final changes.

Good point. I'll add this to an existing example.

[6a6d74]

@rjksmith - are you ready for publication now?

[rjksmith]

@6a6d74 I added an example which includes a WebVMT media path in PR w3c/sdw#1406.

I believe that leap seconds are out of scope for the media timeline, and I'm unable to address the Poincaré synchronisation issue without more information - see above.

In summary, I'm ready to publish. Would you like me to update from 'Draft Note' to 'Note'?

[6a6d74]

@rjksmith - apologies for tardy response. Can I defer this question to @lvdbrink who will push the draft through publication. She's on vacation until the end of this week.

[lvdbrink]

We need a group decision to publish before we can actually complete the publication. Since we missed the plenary meeting last week, it'll have to be proposed via the email list and have a small time window for people to disagree. I'll make it 2 weeks. Will send out that email now.

[lvdbrink]

By the way @rjksmith , I see 14 errors and 202 warnings in the current draft. I'll hold that proposal until you indicate if you can fix those soon.

[rjksmith]

@lvdbrink I see no Respec errors or warnings in Firefox or Chrome. I'm happy to fix any issues if you can give me further details. Please advise.

[lvdbrink]

I don't see them anymore either in my browser. Must have been some loading issue or whatever...

[chris-little]

@rjksmith Apologies for the delay in responding to your request for more info on synchronisation of clocks (a la Poincare). If clocks are stationary wrt each other, one clock sends its time to the second clock. Second clock set to that time and sends that time back. Clock one now has round trip time, splits the difference and tells clock two to retard its time by the same amount. Both clocks now perfectly, mathematically, synchronized, irrespective of distance between them, as outward and return legs take identical times. If clocks are moving wrt each other, the return leg takes a different time, so protocol doesn't work. Assuming message transmission speed is much greater than clocks' relative speed should be good enough (e.g. speed of light/electricity vs few metres/sec), otherwise process has to be iterated until required precision reached. HTH, Chris. PS See "A Brief History of Timekeeping" by Chad Orzel, P189 in paperback edition.

[rjksmith]

@chris-little Thanks for the explanation. I understand the issue now.

The calculation with stationary clocks relies on symmetry and assumes that:

• the distance between the two clocks remains constant
• the second clock responds without delay

I agree that if either clock is moving relative to the other then the symmetry is broken and the result is invalid. However, if both clocks geotag their signals then the system you describe can be refined to work with moving clocks. Clock one can calculate the distances of the outward and return legs and pro rata the round trip time to calculate the required time offset, which is a generalisation of the non-moving case.

Assuming I've understood correctly, WebVMT provides a mechanism to do precisely this and resolve the issue.

[chris-little]

@rjksmith Agreed that if the master clock knows the whereabouts, or rather distances and speed, of the seondary clock, it can be made to work. And speeds are slow compared to transmission speeds. Happy to close this issue.

[rjksmith]

I believe that all review issues have now been addressed, and I've updated the document status to Note (from Draft Note)