RE: Storing data related to SVG elements

> From:	Jon Ferraiolo [SMTP:jferraio@Adobe.COM]
> 
> SVG working group changed the SVG DTD with the June 29 spec to allow
> 
	Last event on http://www.w3.org/Graphics/SVG/
	is dated 20th April (revalidation forced).

> <metadata> elements attached to any SVG graphics or container element.
> 
	[DJW:]  I think real metadata should be attributes not
	content; content should be reserved for information that
	would normally get rendered.  (I don't like the HTML <meta>
	element, particularly as some of the things it does were
	already done better using <link>, e.g. author.)

	If there is a need for extensive structured embedded metadata, I
think
	the real route to take is to get the facility added to SGML,
	then merged into XML, rather than overloading mechanism intended
	to carry document content.

	I think the only meaningful interpretation of the data
	described here as metadata would be as "source code" meta
	data.  It seems to me that it is a higher level equivalent
	of the objects.

	Incidentally, the examples in the June 29th spec
	appear to me to be real metadata, not the sort of
	data under discussion here.

	Looking back at the original question, I think that using
	SVG directly is too physical an approach.  I think either 
	the additional data should be in a linked to, possibly XHTML,
	document (which would give the best accessibility characteristics),
	or failing that, there should be a custom document type which 
	is run time transformed into SVG before rendering.  I'm pretty
	sure that's how SVG is supposed to be used as part of more
	complex documents, but I haven't looked at things closely 
	enough to know whether one can realistically integrate events
	on the transformed SVG back into operations on the original 
	document.

	I.E. by asking for an SVG solution, the questioner is falling
	into the common computing trap of trying to do everthing with
	the one fashionable tool, rather than using a mix of tools.

Received on Monday, 10 July 2000 14:12:20 UTC