Re: [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/).

Many thanks for these detailed and thoughtful comments.

> [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.

A) We thank you for these encouraging words, and agree that a core spec for
mobile plus extensions for full seems to have been a useful lapproach to
take.

> 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.

B) These are good points and we believe we have addressed them with the
next version of the SVG-t 1.2 specification. With the latest spec, we
believe we have improved the processing model around versioning,
extensibility, and subset profiles with sections C.2 Unsupported
elements, attributes, properties, attribute values and property values
and C.4 Namespace, version, baseProfile, requiredFeatures and
requiredExtensions

For more about the changes we have made, please refer to this email
http://lists.w3.org/Archives/Public/www-svg/2005Nov/0073.html
which responds to the issues raised by
http://lists.w3.org/Archives/Public/www-svg/2005May/0147.html

With the new wording, it is clear that an SVGT1.2 user agent will
render those elements, attributes, and properties that it recognizes
and treat all other markup as "unsupported", which means that
the UA renders the content as if the unsupported markup was not present.

It is also clear that if the content includes baseProfile="full", then
the UA should warn the user that it does not support all features 
required by the content.

> 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.

C) Looking at the SMIL 2.0 specification, it became clear that SVG 1.1
should not have used an image element to point to animated vector
graphics content; SMIL differentiates between static raster and animated
vector graphics. In SVG Tiny 1.1, only raster graphics were pointed to
with the image element. SVG Tiny 1.2 continues that, and adds the
missing animation element for animated vector graphics. Also in SVG 1.2
there are further differences, regarding whether an element is timed or
not, whether it produces a viewbox or not, whether clipping is needed
(raster graphics cannot have content outside their pixel extent, while
vector graphics can have content outside their viewbox). In consequence,
we believe the division of functionality between the image and animation
elements to have been a wise one.

We agree that the primary types for IETF media types are sometimes
confusingly named - for example double-byte text does not fit within
their text type, the requirements for the video type encompass some
things that are not really video, and application is used for many
things including text and graphics.

> 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.

D) On reflection, we believe that the wording in the specification is
satisfactory. SVGT1.2 represents a baseline from both the addition and
subtraction perspective. It is a baseline which can be extended or a
baseline which can be subsetted. The wording just says that if an
implementation does not support the baseline completely, it needs to
state the subset of the baseline that it does support. However, we
changed the word for better clarity. Instead of "It must state...", it
now says "the UA's conformance claims must state...".

> 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.

E) The WG agrees fully with the thinking behind this comment, and we
invested many hours of discussions over the course of many WG sessions
spanning calendar years where we engaged SVG experts who understood the
objectives of "clear building block considerations" and mobile video
experts who understood the technical constraints and marketplace
requirements around mobile video placed within a rich UI expressed via
SVG. We believe we came up with a "building block" approach which fits
into a clear long-term vision of an appropriate general-purpose
processing model. The two new general-purpose building blocks that were
added to the processing model are overlays and the extensions to the
'ref' attribute. Both of these new features were designed to fit into an
extended SVG processing model in a clear manner which will not cause
difficulty as SVG is integrated into compound document scenarios. Both
of these features address multiple outstanding requirements that have
come from the SVG community. For example, the 'overlay' feature
addresses a requirement for UI popups and the 'ref' feature addresses a
requirement from the CAD and mapping communities for some aspects of the
graphic content to be non-scaling under zooming scenarios.

> 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.

F) The WG has discussed this, and found that a separate attribute did
not significantly improve backwards compatibility with 1.1 - if a
1.2-only feature is used, then the content is 1.2-only unless a switch
is used. Moving the ref part out into another attribute ensures that the
syntax of transform is still understood, but the semantics are not
preserved as the place that the transform is relative to will not be
understood by a 1.1 implementation.

> 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."

G) We agree and have altered the syntax such that an IRI reference is
allowed here as well. Thanks for pointing out this inconsistency. You
are right that the use of IRI references rather than IDREFS is a design
goal.

> 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.

H) We agree and have moved "Section 10.13 Text selection and clipboard
operations" into the Implementation Requirements appendix.

> 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.

I) This is a good general suggestion which we have heard from at least
one other reviewer. However, we will not do a pass through the entire
specification looking for how to improve the expression of the content
because most of the specification represents text from SVG 1.0 and 1.1
which has proven to be sufficiently understandable to implementers and
content creators.

Instead, we will respond to specific suggestions relative to particular
sections of the specification. For example, we have made improvements to
the spec about what is UA behavior, what is conformant content, etc.

> 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.

J) Your argument clearly has merit. However, section 7.14 is inherited
from SVG 1.1 and thus has already been reviewed and approved by a W3C
Recommendation, and we believe that the approach is technically sound.

We have clarified that this is metadata and does not, of itself,
interfere with rendering in any way. However, we find that there was a
lack of clarity regarding how a real-world mapping coordinate system
would be related to the SVG coordinate system. We therefore find that
the explanation in the specification was needed.

Some parts of the industry have integrated GIS systems or location-based
systems with SVG following the recommended approach from 7.14. At this
point, we choose to leave this section as is and not disturb existing
industry momentum; the optional metadata has resulted in a useful
increase in interoperability in this area.

> 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.

K) We are aware that these things will be taken over eventually and we
have tried to design this so that it can be taken over by another group
without too much effort. Network interfaces for dynamic, data-driven
graphics represent a very real market need and are explicitly listed as
in scope in the SVG WG charter. This is after all not just Graphics, but
Web Graphics.

> 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.

L) We are aware of the problems with CSS2 implementation uptake and
interoperability. Some of these, such as CSS2 selectors, only affect SVG
1.2 Full and not SVG 1.2 Tiny. Some of the least interoperable portions
that have been most changed in CSS2.1, such as parts of the box model
and relative/absolute positioning, are not used in SVG at all.

The font-related areas are in fact better implemented in SVG
implementations than they are in HTML/CSS implementations - this
includes referencing font glyphs in SVG which is widely implemented in
mny different implementations. For HTML implementations, the problems
were
a) poor uptake (only a single implementation on one platform)
b) lack of a mandated font format

For SVG, there has been significant uptake and there is a mandated font
format, which solves the problems CSS2 faced.

Parts of the font handling in CSS2 have also unfortunately been removed
from CSS2.1 The parts that remain and are used by SVG are the same in CSS
2.0 and CSS 2.1.

Overall, we are unable to reference the CSS2.1 Working Draft at this
stage, because needed functionality has been removed. We have however
tracked some useful changes such as saying, for each property, what the
computed value is.


> 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.

M) TransformBehavior is not a hint but an explicit behavioral
instruction to the user agent. Its naming is therefore appropriate.

> 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.

N) The intent was to indicate a model; it was not to mandate the use of
a SAX parser. We agree that this would be undesirable. We have clarified
the spec in this area so that it no longer mentions SAX.


> 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.

O) Thank you for this comment, we have changed tBreak to be tbreak, for
consistency with tspan and tref. textArea remains camelcased for
consistency with textPath.

> 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.

P) We have clarified the spec to state that this is a content
conformance issue; implementations are free to retain a higher precision
and will likely need to use a higher precision for intermediate
computations.

  <integer>: An <integer> is specified as an optional sign character
  ('+' or '-') followed by one or more digits "0" to "9". If the sign
  character is not present, the number is non-negative.

  Conforming SVG Tiny 1.2 content must use <integer> with a range of
  -32,768 to 32,767.

For real numbers, the spec says

  Conforming SVG Tiny 1.2 content must use <number> with the capacity
  for a fixed point number in the range '-32,767.9999 to +32,767.9999'.
  It is recommended that higher precision floating point storage and
  computation be performed on operations such as coordinate system
  transformations to provide the best possible precision and to prevent
  round-off errors.


Many thanks for these detailed and useful comments. Please let us know
shortly if these responses do not satisfactorily respond to your
concerns. A new Last call draft will be made available soon so that you
may check the changes we have made in context.


-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Tuesday, 29 November 2005 20:09:28 UTC