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

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