Re: New draft of SVG Tiny 1.2

On Fri, 21 Jul 2006, Chris Lilley wrote:
> 
> A new draft of the SVG Tiny 1.2 sopecification has just been published. 
> http://www.w3.org/TR/2006/WD-SVGMobile12-20060721/

Excellent news. I will endeavour to review this specification.


> A disposition of comments document is also available: 
> http://www.w3.org/TR/2006/WD-SVGMobile12-20060721/lc3-replies-public.html
> 
> Please let us know shortly if you submitted a comment and the 
> specification does not reflect the agreed changes.

Most of the disagreements do not make it clear what the argument of the 
commentor is, thus making the arguments look specious. This is 
disingenous. I would request that the disposition of comments be balanced. 
For example, in comment SVGT12-392, as well as:

   Resolution: We want to keep it, and we don't have the same box or area 
   model as CSS or XSL, so we need to define it. Its based off existing 
   SVG-Tiny mechanisms for a fixed line increment.

...I would like to see added:

   Argument: The commentor requested that this feature be removed because 
   it is redundant with existing W3C technologies, specifically HTML and 
   CSS: the rendering opportunities afforded by the 'line-increment' 
   feature could easily be achieved using <foreignObject> as shown in the
   response from Ian Hickson cited above.

In comment SVGT12-395 I would like to see it clearly noted that the SVGWG 
is violating the W3C process by not even providing technical reasoning. 
For example, by including:

   Note: We have not replied to this issue with technical reasoning, 
   despite requests to do so from the commentor. (See the last two 
   responses from Ian Hickson cited above.)

In comment SVGT12-396, I would like my objection more clearly indicated, 
for example by adding:

   Argument: The commentor disagrees that AWWW has been followed, the 
   primary example being issue SVGT12-395.

In comment SVGT12-400, I find the entire summary of the issue to be highly 
disingenous and misleading. The specification makes an unclear 
requirement, yet the SVG WG has refused to even attempt to clarify it. The 
two resolutions listed in the disposition of comments weren't even sent to 
the list in reply to my comment, providing no opportunity for me to even 
point out the clear mistakes that the group has made.

In comment SVGT12-417, the group makes an assertion, that the spec is well 
defined. This is clearly not the case, so I would like the disposition of 
comments to have the following added:

   Argument: The commentor disagrees that the spec is well-defined, and 
   asserts that the SVG specification, as written, contradicts the XLink 
   specification. The commentor further comments that this effectively
   prevents any implementor from implementing SVG and XLink in a 
   consistent and useful manner.

Please mark issue SVGT12-311 as unresolved, with the note that:

   Argument: The commentor believes that leaving this unspecified will 
   result in interoperability problems, resoluting in different UAs having 
   to reverse engineer the de-facto standard from each other instead of 
   being able to rely on the specification.

I have not had the time to check all the other issues yet, but it is 
frightening to me that this disposition of comments, even with some issues 
unresolved yet marked as resolved (such as SVGT12-311), still has nearly 
7% of issues marked as unresolved -- and a total of 33% of the issues 
overall resulted in no change to the spec.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 21 July 2006 20:20:34 UTC