[SVGT12 Comment] ACCESS comments on SVG Tiny 1.2 last call WD 040917

Dear SVG experts:

Enclosed please find the ACCESS comments on SVG Tiny 1.2 last call WD.

Toshihiko Yamakami
(on authorization of (Tomihisa Kamada, W3C AC Rep. of ACCESS Co., Ltd.) )

--------------------------------------------------------------
+++ Last Call Comments from ACCESS on SVG Tiny 1.2 2004.09.17

We welcome the specification towards the industry-agreeable mobile
Internet profile of SVG that fits advanced mobile handsets beyond SVG
Tiny 1.1

As the implementors, we would like make several recommendations and
minor comments.

(a) Recommendations
(a-1) General Recommendations
As implementers, we think SVG Tiny 1.2 explores many important features
in the mobile domain, however, it is a little bit heavy for any
implementers.
The use cases and implementation hardness discussions could continue for
a long time.
We can set the certain general design criteria for adapting a mobile
profile:
(rule 1) it should have clear evolution direction in the series of the
W3C recommendations,
(rule 2) it should avoid the unwritten fragmentations.

On rule 1, when we specify something in the mobile domain, there exists
a strong temptation that we invent something which exists only in the
mobile domain. In order to overcome some difficulties in the mobile
domain or to make use of the specific features in the mobile domain,
such a temptation lures. We should resist against such temptations.
Considering the general trend for the convergence between the mobile
Internet and the PC Internet, the W3C recommendation follows the generic
trend towards PC Internet convergence.
>From this point, we recommend that SVG Tiny 1.2 stick to the subset of
SVG 1.1, as a way of the natural transition from SVG Tiny 1.1 to SVG
1.1. The uDOM is not compatible to SVG 1.1 DOM.
Sometimes it is very attractive to skip some old heritage in order to
keep up with the latest development.
We don't think such a quick jump will benefit the market in the long run.

On rule 2, the video formats are untouched to let the market develop the
suitable format for each handset category. We recommend avoiding such
elements to suppress the unwritten fragmentations of the market.

Our recommendation is to use these design rules to make a widely
acceptable SVG Tiny 1.2 specification.

(a-2) Procedural Recommendations
The final resolutions on the SVG Tiny 1.2 inevitably involve the
arguments for hardness in implementations.
The current W3C process document (like 7.4.3 Call for Implementations)
lacks the consideration to the Profile in the mobile domain. It demands
for implement-ability to avoid some castle-in-the-air specifications.
The mobile profile does not make practical sense that the aligned
implementation fits certain reasonable resource constraints.
We recommend that SVG Tiny 1.2 call for implementations set reasonable
resource constraints in the implementations, at least memory size.

(b) Minor Comments
(b-1) minor procedural comments
The SVG Tiny 1.2 heavily depends on SVG 1.2 on feature description.
It will cast some uncertainty of process when we complete SVG Tiny 1.2
last call before SVG 1.2 last call, considering the implicit dependency.

(b-2) minor general comments
It is a good practice to make a litmus test like "when a project manager
come and want to use SVG Tiny 1.2 for the content language, it is
possible for him/her to understand the specification in 10 minutes?".
There are some examples of encapsulation for improved comprehensiveness.
SMIL Animation is reused in specifications. Another example may be sXBL
in SVG 1.2. The spec (at least SVG 1.2 spec) needs further decomposition
for comprehensiveness (especially for content authors).
The practical advices include the difference between SVG Tiny 1.1 and
SVG Tiny 1.2.

(b-3) minor editorial comments
It is not a flaw of the draft and does not impact implementations much,
however, we would like to draw some attentions to the point that the
language-dependent features should be clearly encapsulated in the future
W3C recommendations. A feature like text wrapping is not applicable to
the language in which there is no white space word boundary separation
(e.g. Japanese). [Location: 8. Text, the fifth paragraph]

<end of comments>