I believe you're missing the point. Fixing the library to conform to tests that are based on syntax is a waste of time because the resulting cues are useless because they are not standards compliant. To make useful cues the parser output needs to conform to the parser rules. There is simply no point in creating cues that are not standards compliant. So let us test the library output based on the parser rules and add debug errors where the syntax is incorrect. This is precisely what the test that I have modified do. I am trying to minimize the effort we all need to put in to achieve a correct result. We can achieve this by only maintaining one set of tests and discarding the one that is incorrect and serves no purpose. And by fixing the parser only once instead of making it output useless cues in one mode and fixing it again to output useful cues.
Kyle Barnhart On 2013-02-04 8:21 PM, "Caitlin Potter" <[email protected]> wrote: > Chris, > > The specification outlines both syntax/grammar rules, as well as parsing > rules for the browser, in different sections. > > 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". We are all (I think) in > agreement that they are both important, and both are relevant to different > applications of the library. > > ________________________________________ > From: > dev-media-bounces+caitlin.potter=senecacollege...@lists.mozilla.org[dev-media-bounces+caitlin.potter= > [email protected]] on behalf of Chris Pearce [ > [email protected]] > Sent: Monday, February 04, 2013 8:04 PM > To: Kyle Barnhart; [email protected] > Subject: Re: WebVTT Parser Standards Compliance > > It's not clear to me what the issue is. > > Are you saying: > > 1. The WebVTT spec specifies the parser algorithm, and > 2. the WebVTT spec specifies a grammar for valid WebVTT cues/files, and > 3. some people don't want to implement the specified parser algorithm? > > Is that the correct? If not can you summarise succinctly what the issue > is please? > > > Chris Pearce. > > > > On 5/02/2013 12:38 p.m., Kyle Barnhart wrote: > > This post stems from a discussion on the Seneca IRC channel and then on > the > > webvtt-dev mailing list. David Humphrey has asked for us to move the > > technical discussion to be this mailing list. > > > > The issue concerns which sections of the WebVTT specification our parser > > library must be compliant with. Everyone agrees we want to make a WebVTT > > implementation that conforms to the specification, so I will only copy a > > few quotes on the subject at the root our disagreement. > > > > This issue is very important because solving is soon will make it clear > how > > the work needs to be done, thus reducing work to change it later (if > > required) or the effort involved in perusing two lines of work. Second, > it > > determines the behavior of WebVTT when it is implemented. > > > > ------------------ > > > > Kyle Barnhart: > > "These [parser rules] are the only rules a parser/interpreter needs to > > comply with, this was the deliberate intention of having a parser > section. > > It is important to note that the interpreter can be written in away way > so > > long as it arrives to the same results as in the parsing specifications. > > There should be test to ensure compliance." > > > > Caitlin Potter: > > "... the parser is modeled after the syntax, because the parser's job is > to > > process input according to that syntax or grammar." > > > > Kyle Barnhart: [By validator I mean it only ensures compliance with the > > syntax rules] > > "If the parser is actually only a validator, when are we writing an > > interpreter? We cannot send anything to a browser to process without > one." > > > > Caitlin Potter: > > "The rules of a parser come from the syntax or grammar. The parser spec > > isn't actually required for interpreting data in the files, because that > > all comes from the grammar, and additional information about the markup > > elements." > > > > ----------------- > > > > To summarize, some maintain that our parser library needs to be compliant > > with the sytnax rules of the specification and so the parser library > tests > > should ensure that. The parser section is not required but useful. I > > maintain that the parser library must conform the parser rules in the > > specification, and that checking syntax rules is not required but useful. > > We both maintain that the test for the parser library should reflect the > > part of the specification that is required. > > > > I have the following quotes from people I have talked with and research > > into the issue I have done. > > > > "When writing something that reads WebVTT files, be very sure to parse it > > as specified by the parser--*not* by reading the syntax and coming up > with > > your own parsing algorithm." > > - Glenn Maynard > > > > "[Syntax rules] are requirements for writing, not for parsing. > Requirements > > in that section don't apply to you." > > - Simon Pieters > > > > "'It's a bit unusual for a standard to specify the parsing algorithm, > but I > > can understand why.' > > It's not unusual for modern specs. It's a much more dependable way of > > getting to consistent behavior than only specifying a format." > > - Glenn Maynard > > > > Also... > > > > "It should follow what implementations do as well. So if there's > something > > strange there it might be a bug in the spec." > > - Velmont > > > > "yeah, what Velmont said. If there's a reason to implement something > other > > than the spec, we should change the spec." > > - Ian Hickson > > > > "If the code is to end up in Gecko, it had better follow the > specification > > to the letter" > > - Ms2ger > > > > Please help us to determine which is the correct approach. > > > > Thank You, > > > > Kyle Barnhart > > _______________________________________________ > 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
