[SVGMobile12] last call WD comments (2005.05.20rev2)

Attached please find ACCESScomments to SVGT1.2 W3C WD 13 April 2005
(http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/).

---------------------
[SVGT1.2 ACCESS comments to SVGT1.2 W3C WD 13 April 2005, ACCESS,
20050520rev2]
Recommendation: We recommend W3C to consider the following suggestions.
Especially, we hope W3C address the discrepancy between SVGFull1.1 and
SVGT1.2
in order to avoid any interoperability issues in treating
"image/svg+xml" for SVGFull1.1
and SVGT1.2.

Suggestions:
We appreciate that W3C SVG Group took a right decision on the order of
specification work: a) to make a
strict mobile profile first, then b) to make a full profile that is a
strict superset.
Also, we appreciate that W3C SVG Group took another right decision on
the position
of Mobile Profile as a baseline document to extend, not a random
picked-up subset
with just marking "supported" or "not supported" on a full spec.
It will soon make a series of troubles when updating or merging with
other profiles
for an integrated XML application.
This is an indication that W3C is taking a right approach for the
today's rapid growing
mobile Internet.

Therefore, we think it is worth making improvement suggestions on
SVGT1.2 Last Call Draft.
There are four suggestions and minor editorial suggestions:
a) compatibility considerations
SVGT1.1 is a subset of SVGFull1.1, and SVGT1.2 is a superset of SVGT1.1.
(SVGFull1.2 is a superset of SVGT1.2).
We wonder how SVGTFull1.1 content is rendered in a SVGT1.2 client.
SVG1.1, a conforming SVGviewer must process image/svg+xml in an image
element.
When W3C intentionally breaks compatibility between SVGFull1.1 and SVGT1.2,
the user agent behavior how to manage incoming image/svg+xml SVGFull1.1
document needs to be specified.

a-1) differentiation between image and animation in 5.7 The 'image' element
Now, SVGT1.2 specifies animation instead of image in Section 5.7.
It brings some concerns in a backwardcompatibility.
It also poses some confusion that "image/svg+xml" are used consistently
in SVGFull1.1 and SVGTiny 1.2, but it is not "image" in SVGTiny1.2.

a-2) reference to subset of SVGT in 1.2.3 Profiling the SVG specification
In the last paragraph, it stated ".. it must state either ... or that it
implements a subset of SVG Tiny."
When there is "a subset of SVG Tiny" in the conformance paragraph, it
contradicts with the "base line
characteristics" of SVG Tiny. We interpret that "baseline" described in
the last paragraph in "Section 1.2
SVG Tiny 1.2" means that is a starting point to extend.

b) clear building block considerations
b-1) processing model in Section 12.3 The 'video' element
"overlay" ignores the ordering rule of SVG.
This type of exception in the processing model will cause
interoperability problems in a long term
when the SVG building blocks will be extended and merged with other
XML application building blocks.
Element-based processing model differentiation will lead
further arbitrary processing model choices when the language is extended.

b-2) ref() extension in Section 7.7.5 The ref() transform value
The transform attribute is equipped with a complicated grammar.
Short-cut ref() extension damages the interoperability to SVG1.1
and interfere the existing implementations.
It is recommended to create a separate attribute for short-cut purpose
for clean design.

b-3) discrepancy of convention in Section 13.9.2 Specifying navigation
In focus related attributes use IDREF not URI.
Other SVG attributes use URI.
Inconsistent use of a document fragment will lead to interoperability
problems
for future extensions.
It should be aligned to "SVG makes extensive use of IRI references [IRI]
to other objects."
in Section 14.3.1 Introduction: IRI fragments and SVG views.

c) packaging features considerations
c-1) user agent behavior separation in section 10.13 Text selection and
clipboard operations
"Section 10.13 Text selection and clipboard operations" is user behavior
specification, not relevant the text module authoring. It is recommended
to mark it clearly as user agent behavior.
SVGTiny 1.2 has some loose rule to describe each feature. Some section
include "An example"
for authoring example, some section inserts examples for user agent
behavior.
It is recommended to separate and use consistent subsection titles
for a) The description of SVG languages, b) user agent behavior, c)
authoring example,
and d) user agent behavior example.
The user agent behavior may need to be extended when the further
integration of languages
happen. This should be separate from the language definition to reflect
the baseline nature of SVGT1.2.

c-2) application dependent feature in Section 7.14 Geographic Coordinate
Systems
GIS related features are not related to SVG building
blocks. Application-dependent features should
be separately specified.

c-3) uDOM in Section A.2
uDOM includes socket-level API, which is out of baseline.
Such external interfaces need to be packaged as appendix
to the baseline spec.
If this is a baseline, it is naturally expected that
the future extension will collide with other XML applications.

d) careful considerations on implementation impacts
d-1) Font in Section 17 Font
In 17.8.1 Overview of font descriptions, it refers to CSS2.
CSS2 was specified in May 1998. Some of the descriptions have
large discrepancies among implementations, therefore, CSS2.1
was Candidate Recommendation in 2004.
It is recommended to accept CSS2.1 as the baseline of spec
and to add it in Section 1.5 Compatibility with Other Standards Efforts.
CSS2.1 is an outcome of the valuable experience in the industry
as stated in Section 1.1 CSS 2.1 vs CSS 2 in
http://www.w3.org/TR/2004/CR-CSS21-20040225.
The Section 15 Fonts are simplified from CSS2 to CSS21 to avoid
interoperability problems.
Defining font glyphs using CSS2 in the mobile handset will reiterate the
problems
encountered in CSS2.
External reference font definition processing in CSS2 is heavy and leads
to interoperability
problems.
It is recommended to update it with CSS2.1.

d-2) transformBehavior in Section 12.3
This should be as a hint like other existing SVG
hints attributes like "color-rendering" and "text-
rendering" in Section 11.11 Rendering hints.
It is recommended to use consistent naming
for rendering hints from authors to client.

d-3) progressive Rendering in Section 5.9.2
This progressive rendering specifies the internal
processing model in relation to SAX parser.
This is an important part of implementation to make
optimization. Such a description interfere the footprint
optimized implementation.
The description on the internal processing model should
be carefully considered and minimized.

Additionally, some very minor editorial comments:
e-1) tBreak in Text module
Text Module has inconsistent naming convention like text, tspan,
tref, and textPath elements in SVGFUll1.1. We have textArea element
and tBreak element with additional inconsistent notation.

e-2) Basic Data Type in Section 4.1
The range of integer is restricted for embedded implementations.
It is not a part of baseline, but should be in appendix.
For mobile implementations, the significant digit rule for real
numbers is required.

<end of comment>