On Tue, Feb 5, 2013 at 12:38 PM, Kyle Barnhart <[email protected]> wrote:
> 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." > Looking at the spec, sections 3.2 and 3.3 provide the normative parsing algorithms. Any WebVTT parser implementation in a browser needs to behave exactly like that. It's a very good idea to structure the parser just like the algorithm in the spec, because then changes to the spec will be relatively easy to make in the implementation, and it will be easier for people to understand how the implementation implements the spec correctly. For the same reasons, the output of the parser implementation should match the outputs of the parsing algorithm in the spec --- i.e., it should produce the "text track list of cues" as a list of parsed cues and for each cue, it should produce a list of implementation objects corresponding exactly to WebVTT Node Objects. I agree the role of section 3.1 is confusing. Gecko could completely ignore it, except that it might be useful to have a conformance-checking mode for developer tools. That's a lot less important than having the browser correctly follow sections 3.2 and 3.3, so I would suggest that if you're going to support a "validation mode", that you add that as an optional feature on top of a parser that follows the structure of sections 3.2 and 3.3. And I would suggest building a working parser before adding any conformance checking features. Thanks, Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
