Re: SVG Revision of HTML5 Proposal (ACTION-117)

Hi, Rob-

Rob Sayre wrote (on 3/23/09 11:31 PM):
> On 3/23/09 11:13 PM, Doug Schepers wrote:
>>
>> The SVG WG has provided such reasoning at length, in our email
>> discussions, in the Requirements section of our proposal [1],
>
> I'm not sure what to make of a proposal that contains requirements. That
> sounds like an order. The HTML WG does not have to accept requirements
> from the SVG WG, just as the SVG WG does not have to accept requirements
> from the HTML WG.

I think you're misinterpreting the intent, sorry if we weren't clear. 
"Requirements" there doesn't mean "requirements on the HTML WG"... it's 
in the sense of "use cases and requirements" for what we see as 
transitioning SVG from a strict-XML format to something with looser 
syntax, given market conditions.  Ian asked for the reasoning behind the 
requests were, and that, in part, is captured in the section labeled 
"Requirements".  No need to read too much into the word.


> Accepting that mutual independence should quickly motivate everyone to
> stop negotiating and start collaborating.

The SVG WG isn't trying to "negotiate" to the exclusion of 
collaboration... we are trying to come up with what the community in 
general finds as the best tradeoff of advantages and disadvantages to 
any given proposal.  We aren't putting up straw men or playing games, we 
are trying to balance changes to SVG with the risks that that brings, 
which is part of W3C consensus.

Adobe, during the last HTML telcon, expressed serious concerns about 
what changing the syntax of SVG from strict XML would mean to their 
clients and toolchains; they are one of the biggest SVG authoring-tool 
vendors.  I share some of the same concerns, and while I might be more 
willing than they are to change SVG to meet a different set of users and 
use cases, I'm not ready to do so whimsically.


>Actually, it only needs to
> motivate some people, since Ian and others are not negotiating, but
> rather focusing on concrete technical problems rather than policy
> ratholes and absurd scope creep into browser UI.

I think Henri Sivonen's proposal for UAs to provide a way to get out the 
error-corrected tree serialization was a serious attempt at solving a 
concrete technical problem, and I think it is worth talking about even 
if it doesn't make it into the spec.

I'm also not interested in policy ratholes (which, honestly, I think the 
HTML design principles perpetuate); I'm interested in the reality of 
what happens if SVG is changed in a way that existing SVG UAs don't 
understand, and how we can minimize the damage that will cause.  And I'm 
interested in seeing HTML defined in a way that doesn't need constant 
updates to solve integration issues with other languages.

If you have specific concrete technical proposals that you think address 
those issues, please put them forth.  Because I don't think the issues 
are solved yet.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Tuesday, 24 March 2009 04:07:10 UTC