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=senecacollege...@lists.mozilla.org] 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
