W3C home > Mailing lists > Public > www-svg@w3.org > July 2010

Re: [SVG1.1F2 LC] mainly previous open issues...

From: Chris Lilley <chris@w3.org>
Date: Mon, 26 Jul 2010 19:04:08 +0200
Message-ID: <06108753.20100726190408@w3.org>
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, 


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.



SVGFragmentIdentifier ::= BareName |

BareName ::= NCName
SVGViewSpec ::= 'svgView(' SVGViewAttributes ')'
SVGViewAttributes ::= SVGViewAttribute |
                      SVGViewAttribute ';' SVGViewAttributes

SVGViewAttribute ::= transformSpec
transformSpec ::= 'transform(' TransformList ')'

would become

SVGFragmentIdentifier ::= BareName |

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:27 UTC