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
