At 04:42 PM 5/12/99 -0500, Shane P. McCarron wrote:
[Tim Bray]
I'm dubious about the modest proposal, but both image/svg or
image/svg-xml
seem much more useful than image/xml. -Tim
[Chris Lilley]
Yes, I agree. And I don't see the value of image/svg-xml, since there is
not likely to be a different, non-xml, svg.
I think that the benefit is to user agents that don't already know what
SVG is. When presented with a resource of type image/svg they need to
punt. If the resource was image/svg-xml it would be clear at least that
it could be parsed as XML, even if rendition would be somewhat useless.
I don't think this is useful, but I think that was the intent of the
original proposal.
Well, actually, since SVG has text elements[1], there's plenty of
potentially useful information in those that an XML-aware search engine
could use to identify the file as relevant to a particular topic.
image/svg-xml would have the benefit of making it obvious to such programs
that there is some chance that they can read and meaningfully process that
information. It would also make it clear that the information in an SVG
file could be edited in a generic XML editor. If you don't have a
custom-to-SVG editor around, that capability could be important.
I'd call it very useful. Talk about a revolution! Graphics with text you
can reliably index, and using generic tools at that!
[1] - http://www.w3.org/TR/1999/WD-SVG-19990412/text.html
Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com