Re: SVGT 1.2: SVG fragment identifiers

On Friday, June 16, 2006, 11:27:17 PM, Maciej wrote:


MS> 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.

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

It would be odd (although upward compatible with 1.1), but at the time I
sent the mail the WG had not discussed Doug's proposal.

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

MS> Does the newly restored text match what SVG 1.1 says?

Yes.

>>> 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.

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

We agree and will say this explicitly.

>>> 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".

MS> Adding "for example" addresses my concern about appearing to place  
MS> 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.

MS> That seems fine to say, but redundant. It also seems to exclude most  
MS> of the mechanisms I listed above, which are not links from documents.

The intent was not to exclude non-document links either.

Its merely introducing the idea that links into SVG originate from
elsewhere, but the fragment part is handled by the SVG user agent (in
accordance with general Web architecture).

MS> Is the spec intended to leave behavior in those cases undefined, or  
MS> 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

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

8. The agent interprets the returned representation according to the
data format specification that corresponds to the representation's
Internet Media Type (ยง3.2) (the value of the HTTP 'Content-Type') in the
relevant IANA registry [MEDIATYPEREG].

You should also scroll down a little to
http://www.w3.org/TR/webarch/#media-type-fragid
which gives further details.

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

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

That is the entire point, which is why your initial assertion that the
SVG spec talks about specific mechanisms for accessing links in other
languages is erroneous.

The data format specification for the destination resource
representation is the one that defines fragment syntax.

-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Tuesday, 20 June 2006 18:35:16 UTC