W3C home > Mailing lists > Public > www-svg@w3.org > February 2006

Re: SVG12: linking restrictions vs AWWW

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 7 Feb 2006 04:30:05 -0800
Message-Id: <BF4DEF20-E0D1-4610-B8EE-75B515C132EC@apple.com>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, www-svg@w3.org
To: Chris Lilley <chris@w3.org>

On Feb 7, 2006, at 3:36 AM, Chris Lilley wrote:

> Contrast this with other schemes - http, file, rtp, etc - where a URI
> could indeed still point to the current document if it happens to have
> the same base. The peculiar nature of the data: scheme means that  
> it can
> never point to the current document. The table notes this.

It might be better to add a single note to clarify that "data:" URIs  
should not be considered to point to the current document, even  
though the data is inline. That is probably where the confusion arose.

> SVG does not constrain URIs to be a limited set. For example, it does
> not say "you can only use http" which would be an example of such a
> restriction.

I think restricting URI schemes available for specific SVG features,  
even if not for all of SVG, would also be an example of such a  

> MS> Just scanning the chart quickly, I found this to be the case for
> MS> "use" and "prefetch" elements. Some elements also have  
> restrictions
> MS> on non-data URIs (such as requiring that they have a fragment
> MS> reference) that are not applied to "data:" URIs, for example  
> "font-
> MS> face-uri" requires a fragment ID on the URI which refers to an SVG
> MS> font element but places no such restriction on "data:" URIs.
> data: URIs cannot have fragment identifiers, as noted in previous last
> call comments.

This does not address the case of "prefetch". I'm not sure if you  
meant to address that, but you did quote my text menitoning it. While  
it may be silly to prefetch a "data:" URL, it does not seem  
especially useful to disallow it. And there may be contexts where it  
is useful, perhaps it leads to a processed representation of the  
resource being cached.

Conversely, it sounds like font-face-uri, when referencing a resource  
other than an SVG <font> element, is restricted to the "data:" URI  
scheme. I am not sure if it is allowed to reference anything but a  
<font> element, I could not tell from reading the description of font- 

> We could remove that column and let people figure it out for  
> themselves,
> but we added this detailed information in response to last call  
> comments
> in the previous round.

To me the level of detail seems more confusing than helpful, it makes  
it seem like "data:" scheme is being special-cased even when it is  
not, and allows it to be special-cased by accident where perhaps this  
is not intended.


P.S. I don't really have any personal objection to the spec special- 
casing data:, it does not seem especially useful or harmful. But it  
seems the cases where it does might be an accident.
Received on Tuesday, 7 February 2006 12:30:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:07 UTC