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

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):
---------------
(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 Sunday, 8 January 2006 02:21:07 UTC