W3C home > Mailing lists > Public > public-media-fragment@w3.org > July 2011

Re: ABNF definition of NPT temporal fragment times

From: Philip Jägenstedt <philipj@opera.com>
Date: Wed, 06 Jul 2011 10:39:12 +0200
To: public-media-fragment@w3.org
Message-ID: <op.vx6vnmbpsr6mfa@kirk>
On Wed, 06 Jul 2011 08:17:30 +0200, Chris Double  
<chris.double@double.co.nz> wrote:

> Parts of the definition of NPT temporal fragments in the spec looks like:
> npttimedef    = [ deftimeformat ":"] ( npttime  [ "," npttime ] ) / (
> "," npttime )
> npt-sec       =  1*DIGIT [ "." *DIGIT ]
> npt-mmss      =  npt-mm ":" npt-ss [ "." *DIGIT]
> npttime       = npt-sec / npt-mmss / npt-hhmmss
> Because the 'npt-sec' clause is the first item in the alternates
> amongst 'npttime', given a temporal fragment of '#t=20:10', I see that
> 'npt-sec' will successfully match, but 'npttimedef' will fail since a
> ':' instead of a ',' follows the first number. Is it expected that
> this will then backtrack to retry the 'npt-mmss' clause? I'm
> unfamiliar with how ABNF definitions in these specs tend to work and
> whether backtracking is the norm. If not, then 'npt-mmss' would never
> match? Should the alternate clauses be re-ordered to work around this
> or is this level of detail not usually worried about in these types of
> specs since the intent is obvious?

I'm no ABNF master myself, but npttime here means that any of npt-sec,  
npt-mmss or npt-hhmmss can match, so yes, if you think about the parser as  
having a pointer into a string that you move forward, then you should  
backtrack if npt-sec does not match.

One point I'm not quite sure about is if the order in the syntax is  
relevant, but as long as the npt-{sec,mmss,hhmmss} productions are  
mutually exclusive that should not matter.

As for intent, I certainly don't think anything should be left up to  
interpretation, regardless of what is the norm :)

Philip Jägenstedt
Core Developer
Opera Software
Received on Wednesday, 6 July 2011 08:39:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:46 UTC