Re: Profiles in SVG 1.2

On Tuesday, March 2, 2004, 7:15:51 PM, Jim wrote:



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

JL> |There has to be a second implementation for the Rec, right? 

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

Jim, try to stay within the bounds of reality.

>> The exit criteria for the Candidate Recommendation phase is at
>> least two interoperable implementations over every feature. This
>> phase will close at 2359Z on 23 June 2002.

http://www.w3.org/TR/2002/CR-SVG11-20020430/

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

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

Yes, clearly.

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

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

;-)

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

JL> I agree with this entirely, my fictional example though was a user
JL> interface provided in SVG - perhaps an interface that allowed
JL> extensive drilldown, animation and customisation of a floorplan of a
JL> building, all implemented with RCC - as it's considerably smaller,
JL> simpler and neater.  However aswell as delivering that the same file
JL> would also deliver a static floorplan for the non-RCC enabled users.

It would be better to have the static viewers get a link to an
external SVG file from the SVG stub,and have the RCC and script
replace that with the dynamic RCC content (again, including the raw
XML they are making this from externally).

JL> Graceful degradation has always been my watchword in web authoring,
JL> however graceful degradation in SVG is far from simple,

The technique I suggested might help here.

JL> and has to be
JL> done client-side, this is nasty.  Seen as SVG Applications should
JL> really be in the application/svg+xml mime-type anyway, and the WG is
JL> going to have to go to the trouble of registering a mime-type, it
JL> might aswell register a 2nd one, and help us with this degradation.

If you got application/svg+xml you would know it was the new stuff. If
you got image/svg+xml you would not know anything, because that is
used for everything currently.

JL> I think I realise I won't convince people now, but it's always been
JL> something I've believed would be useful, and the "it's too difficult
JL> to get servers configured" isn't one I particularly buy.

I do,and i think its widely ignored how little control most content
developers have over their server.

JL> Especially as SVG has already shown how easy it is to get servers
JL> configured with wholly made up mime-types.

Yeah, you just have to sit on the same committee as someone with
high-level ties into the Apache foundation and bug them about it
incessantly until they add it.

This is not a route the average SVG content developer can take.

</chris reason="train">

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

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

JL> Jim.




-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Wednesday, 3 March 2004 01:57:31 UTC