Metadata rationale

Hi,

In http://www.w3.org/TR/SVG/metadata.html#MetadataElement

This is said about the metadata element:
| It is strongly recommended that at most one 'metadata' element appear
| as a child of any particular element, and that this element appear
| before any other child elements (except possibly 'desc' or 'title'
| elements) or character data content.

Is it possible to explain this "strongly recommended" - what are the
reasons for the recommendation, if the metadata is RDF (and everyone
seems happy that it's a good idea if it is.) then I don't understand
either of the restriction, both the single metadata element, and having
the metadata first.

Tools that can read RDF inside other documents, have no problems and can
happily cope with the multiple instances (putting
http://jibbering.com/2002/8/rocky2.svg into
http://www.w3.org/RDF/Validator returns all the statements from the three
rdf elements - as does my own simplistic RDF parser from inside SVG -
http://jibbering.com/2002/8/rocky2-parser.svg  so from an RDF perspective
the restriction doesn't seem to make sense.

Having the metadata first also means that High Quality Dynamic Conforming
viewers (who are rendering as they go) have to parse all the metadata
before they can provide content, because of this I'd like to put metadata
at the end of each group/document so as not to delay parsing/rendering of
the visual content.

| If metadata-processing user
| agents need to choose among multiple 'metadata' elements for
| processing (e.g., to decide which string to use for a tooltip), the
| user agent shall choose the first one.

I don't understand this restriction either or what exactly the e.g. is
refering to, all the metadata examples I've seen are about embedding RDF,
not tooltips.

Like with the desc having a xlink:href attribute defined for it to point
to a url which describes the element (like longdesc in HTML images etc.)
it would be nice if the metadata element also had the ability to refer to
seperate files for metadata.

Cheers,

Jim.

Received on Friday, 9 August 2002 12:54:36 UTC