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 18:15:51 +0000 (UTC)
To: www-svg@w3.org
Message-ID: <loom.20040302T190242-412@post.gmane.org>

Peter Sorotokin <psorotok <at> adobe.com> writes:

|At 02:13 PM 3/2/2004 +0000, Jim Ley wrote:
|>>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?
|There has to be a second implementation for the Rec, right? 

Erm, I thought only one actually, and even that's regularly stretched...

|RCC is not hard to implement. 
|so it's not like there totally no new open source work in this area.

Oh no, I'm sure it will be implemented, it doesn't look too hard to implement 
and very powerful, but that doesn't change the fact that there are legacy UA's 
which I (and hopefully other developers) will wish to support.

|Oh, have you came across a 200k RCC component? 

I had one at 100k, but it didn't really work too well, and I ran into a few 
bugs in the preview viewer, I'll revisit it when there's an update 
<hint/><hint/> :-) 

|In my experience RCC tends
|to make things smaller, not bigger.

I agree with this entirely, my fictional example though was a user
interface provided in SVG - perhaps an interface that allowed
extensive drilldown, animation and customisation of a floorplan of a
building, all implemented with RCC - as it's considerably smaller,
simpler and neater.  However aswell as delivering that the same file
would also deliver a static floorplan for the non-RCC enabled users.
Graceful degradation has always been my watchword in web authoring,
however graceful degradation in SVG is far from simple, and has to be
done client-side, this is nasty.  Seen as SVG Applications should
really be in the application/svg+xml mime-type anyway, and the WG is
going to have to go to the trouble of registering a mime-type, it
might aswell register a 2nd one, and help us with this degradation.

I think I realise I won't convince people now, but it's always been
something I've believed would be useful, and the "it's too difficult
to get servers configured" isn't one I particularly buy.  Especially
as SVG has already shown how easy it is to get servers configured with
wholly made up mime-types.

|>Nope, I feel it's a rather complicated goal, and would much rather deal 
|>with it outside of the document.
|I'd rather keep the document clean. Having both RCC and static content in
|one file seems like a mess.

Yep, so give me application/svg+xml and I can negotiate it on the server...

Received on Tuesday, 2 March 2004 13:15:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:00 UTC