Re: [SVG 1.2] Other notes.

Jim Ley wrote:
> 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?

We have users clamouring for it that happen to be the same users that 
would want a profile that forbids extensibility. And I don't think those 
users are Joe Vector Foo in his garage, but possibly much larger 
entities :) But forgetting about the "marketing" reasons, this means 
that XLink clients can understand the purpose of what's done without any 
knownlegde of the vocabulary, which is good.

It'll take time, but XLink will prevail :)

> 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.

I love the ways in which you manage to be brilliantly silly ;) SVG user 
agents need not support that copyright information, the simple fact of 
stating it is legally binding for whom may want to copy content, which 
is why it's recommended to use it (as some people seem to require that). 
The UA has no defined behaviour for RDF copyrights.

Of course, integrating the RDF model into SVG 2.0 would be a worthy 
goal, especially for RCC. But that's another story.

> 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.

I totally agree with that, the current interface is too limitative and 
too brittle. Giving script authors more power is more interesting. With 
any hope that'll bring more use of XMP -- which is meant precisely to be 
locatable in any random binary stream -- and from there lead to more 
interop and more RDFness.

> 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 :-)

Its absence was an oversight of previous specs. But yes getting rid of 
PIs would be a good idea. It's very unlikely we'll deprecate them 
straight away, but if something smart happens in the areas of XML 
Subsetting and XML Processing Model (allowing one to say which element 
points to a stylesheet) then we'll have good ground one which to build 
better UAs :)

--
Robin

Received on Saturday, 15 November 2003 15:19:29 UTC