Re: SVGT 1.2: Addendum: <svg:image> support of external SVG content

Eric and Maciej,
This is the response from the SVG Working Group to the comments first
raised with:
http://lists.w3.org/Archives/Public/www-svg/2005Dec/0310.html

The SVG Working Group did in fact revisit this issue as requested by
Eric and, despite some disagreement within the WG (from at least from
one person), the WG decided to stick with its decision that, in
conforming Tiny 1.2 content, svg:image cannot reference SVG content. The
reasoning I listed in an earlier email still applies:
http://lists.w3.org/Archives/Public/www-svg/2006Jan/0170. (Note: that
email references previous last call response on the same subject.)

In response to Maciej's questions:

Q: "In SVG Tiny 1.2, the 'image' must reference content that is a raster

image format, such as PNG and JPG. SVG Tiny 1.2 does not allow an SVG  
document to be referenced by the 'image' element; instead, authors  
should use the 'animation' element for referencing SVG Documents.  
Conforming SVG viewers must support PNG and JPEG image file  formats.  
Other image file formats may be supported."
The "must" here sounds like a requirement on the document, not on  
user agents. Is it meant to be a UA requirement as well? It's also  
unclear whether other vector (but non-animated) image formats should  
be allowed. For example, would it be legal for an <svg:image> element  
to reference PDF content, if the UA supported this?

Yes, the "must" is a requirement on the content. Conforming SVG Tiny 1.2
user agents are NOT REQUIRED to support SVG content, but there is no
restriction that prevents supporting SVG content. Of particular interest
to desktop SVG implementations will might want to support both Full 1.1
and Tiny 1.2, it is indeed allowed that an SVG UA that supports Tiny 1.2
can also support svg:image referencing SVG content (for compatibility
with the Full 1.1 specification).

Similarly, SVG viewers may also support other formats such as PDF.
However, if SVG Tiny 1.2 content references PDF via svg:image without
including an appropriate 'requiredExtensions' attribute within the
content, then the SVG file is not conformant Tiny 1.2 content.

Q: Perhaps it would make more sense to specify that when an SVG is  
referenced as an image (via <xhtml:img>, <svg:image> or CSS  
background-image) it should provide only static rendering  
capabilities, without animation or scripting (the "Conforming Static  
SVG Interpreter" level of support). This would be a more sensible  
requirement in the XHTML and CSS case (DOM scripting inside CSS  
background images is a scary concept) and would not create any  
semantic difficulties for <image> vs. <animation>.

In situation where XHTML or CSS reference an SVG file, the issue moves
over into the domain of the CDF Working Group. There has been
considerable discussion in the CDF WG about how this should work across
various scenarios. I expect that the latest WICD
(http://www.w3.org/TR/WICD/#svg-child-object) specification reflects the
most current thinking within the CDF working group. The CDF
specifications entered Last Call fairly recently.

Please tell us within two weeks if this response is not acceptable.

Jon Ferraiolo
Adobe Systems, Inc.
Member SVG WG


--------------

From: Maciej Stachowiak <mjs@apple.com> 
Date: Sat, 7 Jan 2006 21:08:44 -0800
Message-Id: <CCB37AE7-5ED3-4003-95E3-DF09D76A76F0@apple.com> 
Cc: Eric Seidel <eseidel@apple.com>, www-svg@w3.org 
To: Jon Ferraiolo <jonf@adobe.com> 


On Jan 7, 2006, at 6:20 PM, Jon Ferraiolo wrote:

>
> Eric,
> I am in 100% agreement about the incongruity of requiring xhtml:img  
> (and
> CSS background-image) to support SVG content, but saying svg:image  
> does
> not. In fact, the depth of incongruity is even greater when taking  
> into
> account the following two facts:
>
> * SVG 1.0 and SVG Full 1.1 require that svg:image support SVG content.
> Thus, if someone is implementing an SVG UA that supports both SVG Full
> 1.1 and SVG Tiny 1.2, according to the current spec, it is unclear  
> what
> such a UA should do if it encounters content which has an svg:image  
> that
> points to SVG content. Should it go into error mode? Render the
> referenced SVG because it can? Check 'baseProfile', and if it says
> 'tiny', then not render the referenced SVG? These questions would not
> come up if SVG-t 1.2 supported SVG content via the svg:image element.
>
> * SVG's MIME type is image/svg+xml, which to me would indicate  
> logically
> that svg:image should be able to reference SVG content.
>
> However, the SVG WG has already discussed this issue (repeatedly) and
> resolved to disallow svg:image to reference SVG content within SVG-t
> 1.2. The rationale is documented in previous Last Call feedback from
> Yamakami-san of ACCESS. Yamakami-san's comment was as follows
> (http://lists.w3.org/Archives/Public/www-svg/2005May/0174.html):

I disagree with the WG's resolution. I think the two reasons you  
stated are strong reasons for not disallowing it, and outweigh  
whatever the SMIL 2.0 spec says. SVG does not use elements from the  
SMIL namespace so it seems to make no practical difference, whereas  
the inconsistency with requirements on XHTML and CSS, and with SVG  
1.1, do.

The actual text in the psec is also unclear on what exactly is  
disallowed:

"In SVG Tiny 1.2, the 'image' must reference content that is a raster  
image format, such as PNG and JPG. SVG Tiny 1.2 does not allow an SVG  
document to be referenced by the 'image' element; instead, authors  
should use the 'animation' element for referencing SVG Documents.  
Conforming SVG viewers must support PNG and JPEG image file  formats.  
Other image file formats may be supported."

The "must" here sounds like a requirement on the document, not on  
user agents. Is it meant to be a UA requirement as well? It's also  
unclear whether other vector (but non-animated) image formats should  
be allowed. For example, would it be legal for an <svg:image> element  
to reference PDF content, if the UA supported this?

Perhaps it would make more sense to specify that when an SVG is  
referenced as an image (via <xhtml:img>, <svg:image> or CSS  
background-image) it should provide only static rendering  
capabilities, without animation or scripting (the "Conforming Static  
SVG Interpreter" level of support). This would be a more sensible  
requirement in the XHTML and CSS case (DOM scripting inside CSS  
background images is a scary concept) and would not create any  
semantic difficulties for <image> vs. <animation>.

I'd like to ask the SVG working group to revisit this issue.

Regares,
Maciej




> ---------------
> (a-1) differentiation between image and animation in 5.7 The 'image'
> element
> Now, SVGT1.2 specifies animation instead of image in Section 5.7.
> It brings some concerns in a backwardcompatibility.
> It also poses some confusion that "image/svg+xml" are used  
> consistently
> in SVGFull1.1 and SVGTiny 1.2, but it is not "image" in SVGTiny1.2.
> ---------------
>
> The official response from the SVG WG
> (http://lists.w3.org/Archives/Public/www-svg/2005Nov/0192) was:
> ---------------
> C) Looking at the SMIL 2.0 specification, it became clear that SVG 1.1
> should not have used an image element to point to animated vector
> graphics content; SMIL differentiates between static raster and  
> animated
> vector graphics. In SVG Tiny 1.1, only raster graphics were pointed to
> with the image element. SVG Tiny 1.2 continues that, and adds the
> missing animation element for animated vector graphics. Also in SVG  
> 1.2
> there are further differences, regarding whether an element is  
> timed or
> not, whether it produces a viewbox or not, whether clipping is needed
> (raster graphics cannot have content outside their pixel extent, while
> vector graphics can have content outside their viewbox). In  
> consequence,
> we believe the division of functionality between the image and  
> animation
> elements to have been a wise one.
>
> We agree that the primary types for IETF media types are sometimes
> confusingly named - for example double-byte text does not fit within
> their text type, the requirements for the video type encompass some
> things that are not really video, and application is used for many
> things including text and graphics.
> ---------------
>
> Jon
>
>
> From: Eric Seidel <eseidel@apple.com>
> Date: Wed, 28 Dec 2005 15:44:53 -0600
> Message-Id: <35CA6E6F-EEA2-4BC4-B115-5BDA5A611646@apple.com>
> To: www-svg@w3.org
>
> == This message seems to have died somewhere in transit, resending. ==
>
> As an addendum to (and further justification of) my earlier comment
> requesting that <svg:image> support referencing whole SVG content.
> It seems silly to me that Conforming SVG viewers (as stated in
> Appendix D) must be allow <xhtml:img> to reference a whole SVG
> document but not <svg:image>
>
> Please correct or clarify this area of the spec per my previous email.
>
> Thanks,
> Eric
>
>

Received on Wednesday, 25 January 2006 04:14:31 UTC