- From: Chris Lilley <chris@w3.org>
- Date: Mon, 26 Jul 2010 19:04:08 +0200
- To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>
- CC: www-svg@w3.org
On Monday, July 26, 2010, 6:30:49 PM, Dr. wrote: DOH> Chris Lilley: >> Hello www-svg, >> Dr. Olaf Hoffmann asked >> ISSUE-2336 >> > 17.3.2 SVG fragment identifiers >> > Is it ok to have the same SVGViewAttribute twice in the one view? >> > If yes, how is this interpreted? >> > http://lists.w3.org/Archives/Public/www-svg/2010May/0026.html >> The intention was not to allow the same SVGViewAttribute twice in the one >> view, no. As you point out, allowing this would not be useful and would be >> hard to interpret the meaning. >> We discussed this, and clarifying directly in the EBNF would make it more >> verbose as the SVGViewAttributes can occur in any order and we did not want >> to impose an order, so the EBNF would need to list each possible >> combination. >> We have therefore added an explanatory note after the EBNF stating that >> each type of SVGViewAttribute can occur at most one time in a given SVG >> View. >> <p>The five types of <span class="code-fragment">SVGViewAttribute</span> >> may occur in any order, but each type may only occur at most one time in a >> correctly formed <span class="code-fragment">SVGViewSpec</span>.</p> >> The initial paragraph of section 17.3.2 SVG fragment identifiers states >> that linking to a view only happens if the fragment identifier is correctly >> formed. Thus, if a viewer met a fragment which was incorrectly formed (from >> having multiple of the same type of SVGViewAttribute, or for any other >> reason) the effect would be that the view was not resolved. >> Please let us know if this clarification is responsive to your comment on >> 17.3.2 SVG fragment identifiers. DOH> I agree that the EBNF is already big enough. DOH> Some additional prose for this issue is the better DOH> and simpler solution. DOH> I can't find the change in the current draft already, http://dev.w3.org/SVG/profiles/1.1F2/master/linking.html#SVGFragmentIdentifiers It will appear in the 'publish' version once the scripts are run to regenerate it. DOH> but this solution DOH> sounds adequate and is ok, of course. Thanks for the confirmation. DOH> Note however that I think, for SVG tiny 1.2 the EBNF can and should DOH> be simplified, in case there will be an update for this version on the DOH> agenda ;o) Yes, the BNF there could certainly be simplified as there is only one type of allowed SVGViewAttribute. http://www.w3.org/TR/SVGTiny12/linking.html#SVGFragmentIdentifiers So SVGFragmentIdentifier ::= BareName | SVGViewSpec BareName ::= NCName SVGViewSpec ::= 'svgView(' SVGViewAttributes ')' SVGViewAttributes ::= SVGViewAttribute | SVGViewAttribute ';' SVGViewAttributes SVGViewAttribute ::= transformSpec transformSpec ::= 'transform(' TransformList ')' would become SVGFragmentIdentifier ::= BareName | SVGViewSpec BareName ::= NCName SVGViewSpec ::= 'svgView(' SVGViewAttribute ')' SVGViewAttribute ::= transformSpec transformSpec ::= 'transform(' TransformList ')' (it could be further simplified to eliminate SVGViewAttribute entirely from the production, but here brevity and consistency are slightly at odds). I will raise this as an errata item. -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Monday, 26 July 2010 17:04:36 UTC