[SVG 1.2] Other notes.


Section 15 Extended XLinks

Why have these?  Implementation cost seems excessive when RCC can provide it
at zero cost to the user, are they really useful enough for situations where
RCC/scripting will not be available?

16.2 Copyright info

Recommending a UA have a full RDF parser purely to access copyright
information seems excessive, whilst I like the idea, I do not feel any user
agents will implement it, simply because RDF is too expensive to add in
plug-in style environments.  If they do, can we please have the RDF parser
included elsewhere!   I'd suggest a simpler copyright disclaimer methodology
that the UA is encouraged to include, with a link to an RDF version.

17.2  SVGMedia interface
    // width and height in pixels (or natural width and height for vector
    readonly unsigned float width;
    readonly unsigned float height;

Is the "natural width for vector formats" also described in pixels?
Are the pixels pixels in the raster sense, or pixels in the CSS sense used
elsewhere in SVG?

getMetadata (str)  - The cost of implementing this seems excessive, and I
don't feel that UA's are likely to do it for more than a couple of metadata
types.  I would like a getAllMetadata()  method which returns all metadata
it has found as a DOMString (or bag of bytes whatever the format is for
that), so it could be a chunk of RDF, or a chunk of EXIF data, and the
script author can then provide the decoding of the metadata, I feel this is
much easier on the UA developer - encouraging widespread interopable
development - and will make more metadata types available to the author who
can parse them herself.

Why do we have xlink:href on the style element, is the PI method deprecated?
I welcome this move away from the general XML methods, and like the
precedent set - lets kill other parts too :-)


Received on Saturday, 15 November 2003 10:30:30 UTC