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

Re: Media Fragments URI parsing: pseudo algorithm code

From: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
Date: Fri, 02 Jul 2010 00:19:28 +0200
Message-ID: <4C2D1470.4000004@eurecom.fr>
To: Philip Jšgenstedt <philipj@opera.com>
CC: Yves Lafon <ylafon@w3.org>, Jack Jansen <Jack.Jansen@cwi.nl>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Media Fragment <public-media-fragment@w3.org>
Dear Philip, all,

@Philip: be ensured that this issue will be handled until we find a 
satisfiable resolution for all parties.

> You cannot write a robust MF parser based on this grammar, because
> t=1&foo=bar is not a valid production, meaning that any future extension
> foo of MF will cause that parser to fail completely. Either the grammar
> itself must be relaxed, or the parsing must be defined normatively and
> handle some things which are not valid productions of the grammar.

It seems to me that this email thread has clarified the point of 
disagreement. I see two things:
   - The fact that the 'segment' production rule is only defined in 
Appendix B of the LCWD document, so it is not normative. I think this is 
clearly a mistake and that the ABNF should also be present in the 
section 4.3.5 "Common Syntax", 
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#common-syntax
   - The fact that respecting purely the ABNF syntax would mean that 
backward compatible MF extensions would be difficult in the future 
according to you.

> Given how long-running this issue is, do we have a bug tracker or other
> formal way of tracking it?

Yes! The tracker is at http://www.w3.org/2008/WebVideo/Fragments/tracker/.
Feel free to enter a new ISSUE using the web interface.

> <issue>
>
> MF parsing must be defined normatively in the MF spec itself, meeting
> these conditions:
>
> 1. should handle all valid productions of the ABNF syntax correctly and,
> where necessary, input which is not valid per the syntax.
>
> 2. must be forward-compatible, so that future extensions to MF do not
> break existing MF parsers. (Compare to how new HTML elements and
> attributes or CSS properties degrade in implementations that don't
> understand them.)
>
> 3. should match as closely as possible how query components on the form
> a=1&b=2 are parsed by existing server-side software (e.g. ASP, PHP, JSP,
> Perl CGI)
>
> </issue>

You can paste this text in the description of the issue. Add a short 
name to the issue. An email will automatically be sent to the mailing list.
Best regards.

   RaphaŽl

-- 
RaphaŽl Troncy
EURECOM, Multimedia Communications Department
2229, route des CrÍtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/
Received on Thursday, 1 July 2010 22:22:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:39 GMT