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

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.

I agree that the EBNF is already big enough.
Some additional prose for this issue is the better
and simpler solution.

I can't find the change in the current draft already, but this solution
sounds adequate and is ok, of course.

Note however that I think, for SVG tiny 1.2 the EBNF can and should
be simplified, in case there will be an update for this version on the 
agenda ;o)

Olaf

Received on Monday, 26 July 2010 16:33:30 UTC