Re: Profiles in SVG 1.2

Jim Ley wrote:
> Robin Berjon <robin.berjon <at> expway.fr> writes:
>>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.

The registration is the least of my worries here (especially since I'm 
not doing it). Updating servers is however an issue, doubly so now that 
Apache ships with the SVG mime type configured by default in mime.types.

The scheme you describe only works if people use it well. Experience has 
shown that even getting the mime type right when there's only one is a 
frequent issue. Under your scheme, people would have to think, pick the 
right file extension, reconfigure servers, etc. What happens if an 
app/svg document is sent to an image only viewer? It breaks. Yet, all 
existing SVG applications are shipped as images. Your suggestion would 
basically break the entirety of existing SVG applications (since they'd 
be routed to a simpler image viewer) and updating the mime type of those 
to app/svg would make them not work on SVG 1.1 user agents even though 
they presently work now.

I certainly like the idea of having a registered application/svg+xml 
mime type, but I think the cost is way too high compared to the value it 
brings us.

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

No, but if you have a UA that does RCC and all the cool app stuff you 
needn't switch to something else for simpler SVG. If you do, you're a 
special donkey deep into SVG and not the typical user.

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

I know. But having FOAFnaut launch TinyLine on my desktop (and thus not 
working) because it uses image/svg+xml and can't switch to 
application/svg+xml until enough people have upgraded their SVG UAs 
isn't much better.

Yes that's what Accept is for, no browsers don't support it properly. We 
apologise for the inconvenience :)

-- 
Robin Berjon

Received on Tuesday, 2 March 2004 10:23:25 UTC