There are tests for every valid and invalid input we could think of. Let me show an example of the changes I've made.
00:01.780 --> 00:02.300 That is a timing statement for a cue. The whitespace between the timestamp and the arrow is required by the syntax rules but not required by the parsing rules. So for tests where the whitespace is missing, I've changed the expected number of cues from 0 to 1. 00:02.0005 The milliseconds are only allowed to have 3 digits. In the current tests change it 00:02.005. This is not allowed by either syntax or parsing rules, and by parsing rules the cue should be discarded. So I changed expected cues from 1 to 0. These are only two of the many changes that had to be made to make the tests correct according to the parsing rules. The other big change I made is to reference the parsing rules being tested in the comments instead of the syntax rules, since the syntax rules don't apply to a parser and the parsing rules do. Otherwise I've made no changes to the intent of any test, and I have added many missing tests, and removed duplicate test. I have not removed any debug error checks and have added many missing ones. In all the modified tests are more thorough and make sure the parser is correctly outputs cues that are standards compliant. What Caitlin is now arguing is that the parsing library should have two settings, one outputs non-standard cues, and one outputs standard cues, and there is a set of tests for each. However I can see no possible reason ever to output non-standard cues. In fact is it bad, dangerous, and a whole lot of unnecessary work. The purpose of a standard is to make sure WebVTT behaves the same in all settings. Outputting non-compliant cues directly violates the standard. Allowing it can only serve to make it more difficult to work with WebVTT, and developers will not know how their file will behave from one application to the next. Therefore it is far less work and far better to have one set of standard compliant tests, and fix the parser to those standards. And it is better to do it now, then to go back and re-engineer the thing later. Thanks, Kyle Barnhart On Mon, Feb 4, 2013 at 8:53 PM, Ralph Giles <[email protected]> wrote: > On 13-02-04 5:20 PM, Caitlin Potter wrote: > > > The issue here is that Kyle insists on rewriting unit tests that are > concerned with the "syntax specification", rather than adding new tests > that are concerned with the "parser specification". > > Like Chris, I'm a confused what the contended issue is. To be clear, are > we looking at the version of the webvtt spec at > https://dev.w3.org/html5/webvtt/ ? > > This has several sections which seem relevant: > > * 3.1 "Syntax" described the WebVTT text format and includes a few > parser descriptions, such as the one for timestamps. > > * 3.2 "Parsing" describes the top-level parsing algorithm for WebVTT > text files. > > * 3.3 "Cue text parsing" describes a parsing algorithm for the contents > of each cue, building a particular dom-ish data structure. > > Is one of these sections the "syntax specification" and another the > "parser specification"? If so, where do they disagree? Can you give a > specific example where one is more permissive or restrictive than another? > > The point of having a specific parser algorithm documented in the spec > is to achieve uniform implementation. If everyone implements the > algorithm (or its equivalent) the handling of edge cases will be more > consistent than if everyone implements a parser from scratch based on > some incomplete syntax description. So we should be implementing the > parser the spec describes. If the spec is internally inconsistent we > should file spec bugs and get the text fixed. > > Nevertheless, the current code doesn't pass--or even run to completion > on--a number of the current tests, so it's difficult to tell what works > and what doesn't. I think fixing that should be the highest priority for > those working on the parser. Without tests we don't know where we stand, or > > Kyle, Caitlin's suggestion that you provide a separate set of parser > tests seems reasonable to me if she wants the current set for code > coverage or additional features. The test sets can always be merged > later if there's consensus that's appropriate. In the meantime you won't > get in each other's way. > > - Ralph > _______________________________________________ > dev-media mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-media > _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
