- From: Yamakami, T. <yam@access.co.jp>
- Date: Sat, 18 Sep 2004 08:16:22 +0900
- To: www-svg@w3.org
- Message-ID: <414B7046.5050005@access.co.jp>
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>
Received on Saturday, 18 September 2004 02:21:25 UTC