WebVMT: Review Editor's Draft - Data Model & Syntax

[rjksmith]

Review initial draft of Data Model and Syntax sections in the Editor's Draft to ensure that sufficient detail is present to implement functions for importing and exporting VMT files, which was proposed as a GitHub activity at the SDW IG F2F Lyon meeting, 22-23 October 2018.

[tidoust]

I'm not entirely clear about design decisions following discussions at TPAC on whether to use WebVTT as:

1. container format, WebVMT being a type of WebVTT metadata track,
2. base format, WebVMT extending WebVTT, or
3. placeholder, pending a generic metadata file format that could perhaps follow a different syntax in the end.

Personally, I would go with 1. to start with and pursue 3., but the current document seems to use 2. I wasn't part of TPAC discussions though!

Sticking to comments that apply in any case:

• I would not duplicate parts already defined in WebVTT. For instance, the definition of a WebVMT style block seems to be the exact same one as the definition of a WebVTT style block, so I would not duplicate its definition. Or I would clarify somewhere that this is the exact same thing.
• The WebVMT media definition block is not specific to maps, does not exist in WebVTT, and yet is defined as mandatory in WebVMT. That seems a good point to discuss with timed text guys if not already done.
• The WebVMT map definition block is interesting because the information it contains needs to be exposed to Web applications somehow, and there is no mechanism to do so for now. That is, even if browsers could parse and expose WebVMT cues as DataCue or as a specific VMTCue, the map information would still need to be exposed somehow. I'd raise that as an open issue at least.
• The Spatial Data on the Web Best Practices have BP 8 - State how coordinate values are encoded. I suspect you're only considering WGS 84 here in WebVMT but that is not specified.
• It may be too early to think about this, but I'm not sure how one could extend the format to add additional metadata without risk of collision with future revisions of the specifications. That could be worth considering

[rjksmith]

@tidoust Thanks for your comments.

I've created separate issues for each of them, as proposed in the F2F meeting in Lyon last month when you were in another meeting, which should help clarify the review process.

• Review design relationship with WebVTT
• Review duplication of WebVTT documentation overlap
• Review media block concept against WebVTT
• Review map block interface exposure
• Review co-ordinate encoding definition
• Review metadata extension mechanism

[chris-little]

Rob,

1. Replace 'able programmer' by 'competent programmer'. Disabled programmers can be competent.
2. Replace 'Google' by 'Open Street Map'. Open Source vendor neutral solution.

[rjksmith]

Updated review issues, including #1096, and the Editor's Draft to address reviewers' comments.

Many thanks for all the feedback and support.