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", 
   - 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 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 UTC

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