W3C home > Mailing lists > Public > public-sdwig@w3.org > December 2018

Re: [sdw] WebVMT: Investigate better out-of-band link handling (#1107)

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Thu, 13 Dec 2018 11:39:42 +0000
To: public-sdwig@w3.org
Message-ID: <issue_comment.created-446938639-1544701181-sysbot+gh@w3.org>
Not that I believe that this issue is that crucial but I think the above summary misses the point that I am trying to make, so allow me to reformulate:

In the image example, the main starting point is the HTML page. If the link is broken, the image won't render. Such an error is easy to detect and fix because it has a practical consequence: the browser fails to fetch the image, cannot render the page properly, and can report a warning. Or the reader sees the broken image and yells one way or the other. In short, someone notices.

The image itself does not link back to the HTML page. Metadata in the image itself could probably include a link back to the HTML page that embeds it. However, such a link is much more error-prone because nothing breaks when that link is broken: browsers won't fetch the link to render the image or to render the HTML page, and these are by far the main usage scenarios. Browsers won't see the error. Users won't see anything wrong either. In short, no one notices.

What could "trigger a warning message if the URL is incorrect and cannot be resolved"? Search engines when they index the content? How would they report the warning? Authoring tools would be able to detect the error, but that supposes that people will use authoring tools, and experience with HTML shows that people are actually happy to write code by hand and copy-and-paste things from one place to another, etc. WebVMT files being text-based would see the same kind of behavior.

I believe the same thing applies to WebVTT, WebVMT, and other out-of-band tracks. Main usage is going to be rendering the video. The starting point will be either the audio/video file, or the HTML page that embeds it, so link should be from the audio/video file or the HTML page to the WebVMT file, and that's going to be the only link that can be somewhat trusted.

For better or worse, links on the Web are not bidirectional. Search engines that index images will manage to reconstruct the link from the image to HTML page(s) simply because they will crawl HTML pages to start with. Similarly, indexation can reconstruct the link from the WebVMT file to the media file(s) by crawling HTML pages and/or media files to start with.

In summary, I'm suggesting that having a link to the media file from the WebVMT file may not be a good idea because it can break easily without practical consequence, and thus is a non reliable source of information. The alternative is not to have a link from the WebVMT file to the media file / HTML page: the link goes the other way round and that seems enough.

-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at https://github.com/w3c/sdw/issues/1107#issuecomment-446938639 using your GitHub account
Received on Thursday, 13 December 2018 11:39:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:52 UTC