W3C home > Mailing lists > Public > www-svg@w3.org > November 2003

SVG1.2 Comments

From: Gavin Kistner <gavin@refinery.com>
Date: Thu, 13 Nov 2003 12:47:18 -0700
Message-Id: <3071B070-1612-11D8-9258-0003937E984E@refinery.com>
Cc: svg-developers@yahoogroups.com
To: www-svg@w3.org

Comment Context
FWIW, here are my initial comments on the SVG1.2 draft. So you may 
classify and sort my comments appropriately, my role is an SVG content 
author, standing with 1.8 feet in the SVG-as-programmable-UI camp.



Section 1
How should the elements be described? I personally prefer DTD over XML 
Schema. IMO a DTD snippet is fine and moderately helpful when 
introducing the element (ala HTML 4.01 specs), but I think it would be 
fine to omit precise specifications inline in the documentation, just 
include a common-case sample or two, leaving the precise syntactic 
specification to a separate-file DTD (or XML Schema).



Section 2, Example #5:
" 5. Implement a new document structure for the SVG specification by 
publishing multiple parts. For example, SVG Part 1 could define the 
core static SVG features; SVG Part 2 could introduce SMIL animation and 
interactivity; SVG Part 3 could define the SVG DOM; and finally Part 4 
would cover the extensibility."

If I understand this correctly to mean "We're going to solve the fight 
between the two camps by reorganizing the documentation into a 
particular order" then I'm not sure how this would help. IMHO example 
#1/2 are the best choices -- provide a clearly-defined profile for each 
of the two camps, and let the UAs state which they support.

In fact (Section 2.1) I really don't understand the difference between 
a 'theme' and a profile. What's the SVG Core 'theme' if not a subset 
profile of the overall ('Extended') specification?


(skipping various sections which are too complex for me to peek at now 
:)


Section 17.2
SVGImage.getPixel() returns an unsigned long. Assuming this is for a 
32-bit RGBA implementation, this seems like a rather annoying data type 
to have to deal with. It takes a bit of bitwise ANDing and shifting to 
get each component out, which is surely what every developer would have 
to do in order to work with this.

The method itself is quite welcome, but I suggest that a full-fledged 
object be returned, with (read-only) direct access to each of the RGBA 
values.

--
Gavin Kistner @ Refinery, Inc.
gavin@refinery.com
work: +1.303.444.1777
Received on Thursday, 13 November 2003 14:47:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 5 November 2012 23:52:55 GMT