Re: SVGT 1.2: SVG fragment identifiers

On Jun 8, 2006, at 9:09 AM, Chris Lilley wrote:

>>
>> 1) Are these points actually calling for different behavior? What is
>> the difference between "the initial view into the SVG document shall
>> be established using the view specification attributes (i.e.,
>> viewBox, etc.) on the 'svg' element" and "the document defined by the
>> rootmost svg element shall be displayed in the viewport using the
>> view specification attributes on the rootmost svg element."? Those
>> sound like they would be the same initial view to me. Therefore it
>> seems like fragment identifiers that address any element have no
>> effect have no effect.
>
> There was an error in the second point, pointed out by other  
> commentors;
> it should be the closest ancestor svg element. (Note that in SVG Tiny
> 1.2, which does not allow nested svg elements, these are the same;the
> difference becomes significant in other profiles which extend Tiny  
> 1.2.

It would be odd, then, for a fragment ID that addresses an element to  
have no effect in SVG Tiny 1.2, but since Doug has pointed out that  
this was changed, I'll respond to his comment instead.

> Compared to SVG 1.1 the intervening bullet about svgView fragments was
> also inadvertently missing, and has been restored.

Does the newly restored text match what SVG 1.1 says?

>> 2) Behavior is not defined for SVG fragment identifiers that do not
>> address an element. This includes both bare names that do not address
>> an element, and svgView()-style fragments. Perhaps the intended
>> behavior is considered obvious, but the spec does not say what it is.
>
> It was indeed considered obvious - since the element cannot be found,
> then its the same as the case where there is no fragment. one gets the
> initial view of the rootmost svg element.

Might be nice to say this explicitly, but no major objection to  
leaving it out.

>> 3) It is inappropriate for the specification to talk about specific
>> mechanisms for accessing links in other languages.
>
> It would be, but we don't. The defining specification for SVG fragment
> identifiers is SVG. This is true whether the links to SVG are in SVG,
> HTML, PDF, WebCGM, or anything else.
>
> To make this clearer we have added "for example" before "via".

Adding "for example" addresses my concern about appearing to place  
requirements only on specific other languages. However see below.

>> Consider some of these other mechanisms for accessing an IRI  
>> reference to an SVG
>> document that includes a fragment identifier: type in location field,
>> click link in external application that is not using any XML or HTML
>> language for display, assign the window.location attribute via
>> script, use window.open() in script, select bookmark or history item
>> from menu.
>
> The intent was not to exclude those. The intent was to make clear that
> links to SVG content, including to SVG fragments, can occur in any
> document.

That seems fine to say, but redundant. It also seems to exclude most  
of the mechanisms I listed above, which are not links from documents.  
Is the spec intended to leave behavior in those cases undefined, or  
are they considered to be in some way "links from documents"?

>
>> Instead of talking about what mechanisms in other
>> languages should do, the spec should say what  the SVG implementation
>> must when presented with an absolute IRI reference that includes a
>> fragment identifier.
>
> No. That is not the same at all.
>
> The procedure when a link (with a fragment) to format foo is found  
> in a
> document of format bar is well described in the Architecture of the
> World Wide Web, Volume 1:
> http://www.w3.org/TR/webarch/#dereference-details

I read section 3.1.1 and did not see a step relating to fragment  
identifiers at all, nor did I see any claim that the language of the  
source document must consider anything specified about the format of  
the target document.

> So it is entirely correct and appropriate to talk about a link to  
> an SVG
> file in a document that is not SVG.

It should be clear though that the requirements are on the SVG  
implementation and not on the implementation of the source document,  
if any.

Regards,
Maciej

Received on Friday, 16 June 2006 21:27:27 UTC