W3C home > Mailing lists > Public > www-svg@w3.org > March 2004

Re: Profiles in SVG 1.2

From: Jim Ley <jim@jibbering.com>
Date: Tue, 2 Mar 2004 14:13:07 +0000 (UTC)
To: www-svg@w3.org
Message-ID: <loom.20040302T145813-32@post.gmane.org>

Robin Berjon <robin.berjon <at> expway.fr> writes:

> Jim Ley wrote:
> > I welcome profiling, but would still like to see an
> > application/svg+xml - I don't make SVG images, I make SVG
> > applications, and I'd like to ensure they end up with a viewer capable
> > of rendering them.
> 
> If I read what you're saying correctly you'd like to have a way to tell 
> more or less the intent of an SVG document (application-orientated or 
> image-orientated) based on the mime type?

Based on something out of band of the document, the mime-type being
the least cost, even if it's not perfect, new headers and educating
configuring proxies etc. would be preferable, and could solve the even
worse issue of application/xml text/xml that Mozilla supposedly
supports.

> There's overhead in that 
> (defining new file extensions, updating servers, etc), 

Not a lot, and wacking it onto the image/svg+xml registration wouldn't
take much effort at all, updating servers sure, that's a bit of
effort, but only people authoring SVG applications need do that.

> As nice as it is, I'm not entirely 
> buying the multiple SVG viewers with different capabilities one.

So Batik, KSVG etc. will become basically useless after Adobe release an RCC 
capable UA until the kind open source developers find the time to implement 
RCC? 

The Use case is simple, getting content to users, if the users UA doesn't 
manage RCC, I need to have that UA degrade, switch may get us there, but it's 
an awful lot of data being shipped, for all the clients.  Shipping 200k of 
RCC'd SVG to TinyLine at 10USD a MB is pretty nasty given that all it'll get at 
best at the end is 5k of static SVG image that it could deal with - In reality 
it's likely to get nothing it can render at all.

>  > Alternatively I'd like to see RCC
>  > etc. reformulated so it will simply degrade to valid static content
>  > showing the same information in SVG 1.1 user agents - at the moment
>  > that degrade path is onerous.
> 
> That is certainly a worthy goal, but do you have a plan for that?

Nope, I feel it's a rather complicated goal, and would much rather deal with it 
outside of the document.

Cheers,

Jim.
Received on Tuesday, 2 March 2004 09:13:10 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:26 GMT