- From: Chris Lilley <chris@w3.org>
- Date: Thu, 10 Aug 2006 16:17:08 +0200
- To: www-svg@w3.org
Hello www-svg,
W3C is pleased to announce that
Scalable Vector Graphics (SVG) Tiny 1.2 Specification
http://www.w3.org/TR/2006/CR-SVGMobile12-20060810/
is a W3C Candidate Recommendation.
Please send your implementation feedback to www-svg@w3.org (which
has a public archive http://lists.w3.org/Archives/Public/www-svg/ ).
The implementation reports should be submitted by 8 November 2006.
This approval and publication is in response to a Transition Request: SVG Tiny 1.2 made on Thu, 3 Aug 2006.
The Working Group received significant review at Last Call and
agreed with commentors for 257 of 297 Last Call comments
received. For complete information about the disposition of
comments, see:
http://www.w3.org/TR/SVGMobile12/lc3-replies-public.html
There were no Formal Objections from participants in the SVG
Working Group, or from other Working Groups. A number of Formal
Objections have been received from the public, detailed below.
The implementation report is in progress at:
http://www.w3.org/Graphics/SVG/1.2/Tiny/ImpReport.html
Patent disclosures relevant to this specification may be found on the
SVG Working Group Patent Policy Status page.
http://www.w3.org/2004/01/pp-impl/19480/status
The document abstract, and status sections are included below.
This Call for Implementations follows section 7.4.3 of the W3C Process
Document:
http://www.w3.org/2005/10/Process-20051014/tr.html#cfi
Thank you,
For Tim Berners-Lee, Director; and
Chris Lilley, Graphics Activity Lead;
Nandini Ramani & Chris Lilley, SVG Working Group Co-Chairs;
Dean Jackson, SVG Working Group Team Contact;
Susan Lesch, W3C Communications Team
===============
Feature at Risk
===============
The behavior when a fragment identifier contains a bare ID and
does not contain a view specification has been modified compared
to SVG 1.1. It is believed that the corrected behavior is more
intuitive (bring the object with the given ID into view, panning
and zooming out if necessary); that the old behavior was
counter-intuitive; and that this change is welcomed by users and
implementors. However, following the CR transition call, this
feature was marked as 'at risk' and, if not interoperably
implemented by the end of the CR period, will be removed and the
old behavior will be reinstated.
==============================================
Quoting from the SVG Tiny 1.2 specification
==============================================
Scalable Vector Graphics (SVG) Tiny 1.2 Specification
W3C Candidate Recommendation - 10 August 2006
This version:
http://www.w3.org/TR/2006/CR-SVGMobile12-20060810/
Abstract
--------
This specification defines the features and syntax for Scalable
Vector Graphics (SVG) Tiny, Version 1.2, a modularized language
for describing two-dimensional vector and mixed vector/raster
graphics in XML. SVG Tiny 1.2 is the baseline profile of SVG,
implementable on a range of devices from cellphones and PDAs to
desktop and laptop computers, and is the core of SVG 1.2. Other
SVG 1.2 specifications will extend this functionality to form
supersets (for example, SVG 1.2 Full).
Status of this Document [Minus some boilerplate]
-----------------------
This is the 10 August 2006 Candidate Recommendation of SVG Tiny
1.2. W3C publishes a Candidate Recommendation to indicate that
the document is believed to be stable and to encourage
implementation by the developer community. The SVG Working
Group expects to request that the Director advance this
document to Proposed Recommendation once the Working Group has
demonstrated at least two interoperable implementations for
each test in the SVG Tiny 1.2 test suite; furthermore, at least
one of the passing implementations must be on a mobile
platform. The SVG Working Group, working closely with the
developer community, expects to show these implementations by
January 2007. This estimate is based on the Working Group's
preliminary implementation report. The Working Group expects to
revise this report over the course of the implementation
period. The Working Group does not plan to request to advance
to Proposed Recommendation prior to 10 November 2006.
This is a W3C Candidate Recommendation. The third Last Call
Working Draft for this specification resulted in a number of
Last Call comments which have all been addressed by the SVG
Working Group; a list of all Last Call comments can be found in
the Last Call Comments List. The list of changes made since the
last public Working Draft is available in Appendix T.
The behavior when a fragment identifier contains a bare ID and
does not contain a view specification has been modified
compared to SVG 1.1. It is believed that the corrected behavior
is more intuitive (bring the object with the given ID into
view, panning and zooming out if necessary); that the old
behavior was counter-intuitive; and that this change is
welcomed by users and implementors. However, following the CR
transition call, this feature was marked as 'at risk' and, if
not interoperably implemented by the end of the CR period, will
be removed and the old behavior will be reinstated.
Please send comments to www-svg@w3.org, the public email list
for issues related to SVG. This list is archived and acceptance
of this archiving policy is requested automatically upon first
post. To subscribe to this list send an email to
www-svg-request@w3.org with the word subscribe in the subject
line.
This document has been produced by the SVG Working Group as
part of the W3C Graphics Activity, following the procedures set
out for the W3C Process. The authors of this document are
listed at the end in the Author List section.
This document was produced by a group operating under the 5
February 2004 W3C Patent Policy. W3C maintains a public list of
any patent disclosures made in connection with the deliverables
of the group; that page also includes instructions for
disclosing a patent. An individual who has actual knowledge of
a patent which the individual believes contains Essential
Claim(s) must disclose the information in accordance with
section 6 of the W3C Patent Policy.
Formal Objections
=================
1. Maciej Stachowiak registered a Formal Objection on 22 March 2006
regarding the provision of a text wrapping facility.
SVG 1.1 already has a mechanism for text breaks (the tspan
element) but requires that the author choose the position of the
break in advance.
For SVG which is generated automatically, or includes strings of
unknown length drawn from a database, or where the font to be
used is not known, it is desirable to allow the line break
positions to be calculated at display time. A common use case is
text callouts on a diagram, which must fit into a rectangle of a
given size and where part numbers etc. are drawn from a database.
Given that this is a popular and much-requested feature, and
given that a critical mass of content authors and implementors
have stated that they want this feature, the SVG Working Group
declined to remove it, over the objection of Maciej
Stachowiak. However, the line wrapping requirements were softened
so that an existing engine (e.g., a CSS or XSL engine) could be
used to perform the wrapping and still be compliant to the SVG
specification. The Director agreed with the Working Group's
approach.
2. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'Process issues and their technical adverse effects'.
The commentor listed a number of comments which he had sent after
the Last Call period had ended, asking why they were not treated
as Last Call comments and why he had not received a response to
them. The Director was satisfied, on being shown the Member-only
issues list, that issues raised after Last Call were being
tracked, as required by W3C Process, and that a response would be
provided in a timely manner. Indeed, many of the comments have
already received responses.
The Last Call Disposition of Comments indicated that there were,
in some cases, several responses to a single email, since a
single email can make multiple points, some of which the Working
Group may agree to, some that require no change, and some that
may end in disagreement. Responses to multiple points are listed
separately in the Last Call Disposition of Comments.
3. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'Pre-mature stability claims and commitments'.
This comment seems to relate to JSR-226, a standard for creation
of SVG Tiny 1.1 content from a Java API. The low memory,
low-overhead approach used in JSR-226, being proven in practice
on many Java-enabled mobile phones, was adopted by the SVG
Working Group as a basis for the micro DOM (uDOM, a DOM Level 3
subset) in SVG Tiny 1.2. The drafts of SVG Tiny 1.2 with this
feature thus appeared at a similar time as the final versions of
JSR-226. Furthermore, there is another JSR, JSR-287, that plans
to do the same for SVG Tiny 1.2 that JSR-226 did for SVG Tiny
1.1.
The benefit of allowing Java programmers to create interactive
displays using SVG, even on very small devices, the widespread
deployment of the earlier JSR-226 version, the upwards
compatibility to SVG Tiny 1.2, and the proven suitability to
constrained devices, seemed to the SVG Working group to be
substantial benefits. Indeed, using this approach, the number of
profiles was reduced from two (one with and one without
programmatic access, in SVG 1.1) to one (SVG Tiny 1.2).
The commentor pointed out a couple of examples where duplicate
interfaces would be needed, to cover both the JSR-226 version and
SVG 1.1. The SVG Working Group acknowledged, in a response to a
Last Call comment, that this small amount of duplication was
regrettable and could have been avoided; but the practical impact
is small.
While acknowledging, therefore, the risk of premature
standardization, the Director concludes that it seems manageable
and that implementation experience to date has been beneficial.
4. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'Overlap with WebAPI deliverables'.
The commentor listed a number of current and future possible
deliverables of the WebAPI Working Group, and requested that
almost all functionality which might potentially be covered be
dropped. (He made an exception for the getURL, postURL, and
parseXML features, which have been widely and interoperably used
for over five years and are standardized in SVG Tiny 1.2).
The commentor stated that some of the functionality was not
required for the Web. The Working Group believes that the
functionality is useful in areas that may not have been
considered by the commentor, such as Web services, embedded
systems, content created for a user interface, and Intranet
usage. One single security model is clearly insufficient for all
cases, and so the SVG Working Group declines to impose a
particular model; instead, implementors should choose a security
model appropriate to the area of use.
Furthermore, the number of use cases where these features,
particularly networked updates for interactive graphics, are
critical suggests that SVG Tiny 1.2 would not succeed in the
market without them.
The WebAPI Working Group itself made no similar comment. The SVG
Working Group charter explicitly lists network functionality for
graphical display updated over a network in scope of the Working
Group. The connection interface was developed in response to
previous Last Call comments asking for it. The DOM Level 3 Events
specification has already been transferred over from SVG to
WebAPI. The specification already states that the mousewheel
functionality, developed in the SVG Working Group since 2001,
will be dropped in favor of the more recent WebAPI alternative if
it proves suitable during the CR period. The Director has thus
suggested to call for implementations and to gather more detailed
interoperability experience rather than wait indefinitely for
possible future specifications that might prove suitable.
5. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'Trait API'.
"Traits" are a feature in SVG Tiny 1.2 which allow script writers
and programmers to obtain typed access to attribute and property
values, rather than having to microparse a string. This has
memory saving, ease of use, interoperability and efficiency
benefits. As an example, a color would be available as three
numbers (for the red, green and blue components) rather than a
string containing one of six different lexical forms.
The commentor laments the lack of a general purpose, typed access
to all the sorts of information that might be desirable --
specifically numerical values with units (3cm, 4in, 24px,
etc). This feature is indeed lacking, and shares with for example
W3C XML Schema, the fact that such types cannot easily be
represented except as a string. However, given that SVG Tiny 1.2
itself does not use values with units, apart from on the root
element to optionally specify a width and height, its absence
does not seem to affect SVG Tiny implementations unduly.
The commentor also suggests that the feature is
"ill-designed". However, the feature has already been implemented
successfully.
The commentor was unable to propose a better solution. Backwards
compatibility further constrains the design space. The Director
looks forward to input from developers during the CR period on
whether the feature is defined in a sufficiently clear fashion.
6. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'Focus navigation'.
SVG Tiny 1.2 allows a content author to indicate a directional
navigation scheme (familiar, for example, from DVD menus and
mobile phone interfaces). Unlike in for example HTML -- where
objects tend to be rectangular and rarely overlap, but are
positioned automaticaly -- in SVG objects are irregular shapes,
possibly disjoint, usually overlap, but have fixed
positions. Automatic determination of navigation (the object
which is 'up' or 'left' of the present one, for example) is
therefore not possible and a navigation scheme must be designed
by the content author.
The commentor asks the SVG Working Group to explain why they do
not use the CSS3 Basic User Interface Module. The Working Group
did use the module in earlier drafts but implementation
experience and inter-Working Group discussion on directional
navigation during Technical Plenary Week in 2006 indicated that
it was not suitable for SVG Tiny 1.2. There is no known algorithm
to automatically determine directional navigation placement in
the general case. Until and unless the CSS Working Group advances
the CSS3 Basic User Interface module farther on the
Recommendation track it would be risky to depend on it.
7. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'XML Events'.
The SVG Tiny 1.2 specification uses XML Events. Version 1.0 of
XML Events, being based on DOM Level 2, lacks support for
namespaced events. SVG Tiny 1.2, being based on DOM Level 3,
would preferably have such support. Following initial
discussions with the HTML Working Group two years ago, the SVG
Working Group made extensions to XML Events to support DOM Level
3 and suggested that the HTML Working Group review namespaced
events and publish them. As this did not happen, the updated XML
Events functionality was copied into the SVG specification.
This was criticized by reviewers in an earlier Last Call, who
said that SVG should use the existing specification not a future
one, even if it was an improvement. Agreeing that what the HTML
Working Group had was better, the SVG Working Group reluctantly
downgraded to XML Events 1.0.
The formal objection concerns this return to XML Events 1.0, and
states that the SVG Working Group version was an improvement and
should be published, in coordination with other Working
Groups. The SVG Working Group agrees with the commentor and plans
to do so.
The commentor also suggests adding a dependency on this future
specification. The Director believes it is preferable to advance
SVG Tiny 1.2 at this time rather than wait for a future version
of XML Events, and to defer full namespaced XML Event support to
a subsequent version of SVG.
8. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'Event-based animation DOM compatibility'.
The commentor is unhappy with a syntactic feature for event-based
triggering of animation. As the commentor notes, this feature is
"inherited from SVG 1.1 and SMIL 2.1" which is largely
correct. SVG Tiny 1.2 is a host language for SMIL 2.1. The
commentor suggests a richer, more powerful, but incompatible
syntax to allow any event, including namespaced events, to be
used. The SVG Working Group has explained that this would be
incompatible with SMIL 2.1. The commentor suggested that SMIL 2.1
be revised to include his proposal. The Director suggests that
these comments be directed to the SYMM Working Group for a future
version of SMIL.
The commentor also objected to the 'event aliasing' feature,
although that feature had already been dropped in response to
Last Call comments.
9. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'Document manipulation vs. SMIL timing'.
The commentor states that insertion of timed elements into a
running timeline is undefined in SMIL 2.1. This is because SMIL
2.1 does not have a DOM and did not address tree
manipulation. However, SMIL Animation did have a DOM and did
address insertion of elements into a timed structure. The
Director agrees with the SVG Working Group's proposal to ask the
SYMM Working Group for specialist advice on this feature. The SVG
Working Group expects to construct test cases for it during the
CR period.
10. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'animateTransform underspecified'.
The commentor points to concerns, some raised as recently as two
weeks ago, regarding the exact behavior of some corner cases in
animateTransform, a feature that has been in SVG since version
1.0. The Working Group is tracking these comments, as required by
Process. The Director asks the Group to explore tests for these
cases during CR and determine whether the corner cases are
interoperable.
11. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'Animation involving dynamic keywords'.
The commentor asserts that animation of a color using the
'currentColor' value is ill-defined. This part of the
specification has been clarified in response to Last Call
comments from other commentors. The commentor asserts that the
value of currentcolor is not defined, when the color property is
animated. The Working Group refers the commenter to this
definition in the specification: "[currentColor] Indicates that
painting shall be done using the color specified by the current
animated value of the 'color' property."
The SVG Working Group has found the commenter's examples useful
and has added them to the specification and as test cases to the
test suite.
The Director recommends that the group verify during the CR
period that the feature can be implemented interoperably.
12. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'Use of unregistered media types'.
The commentor objects to the use of the Internet Media type
application/java-archive in examples, on the grounds that it is
unregistered with IANA. He suggests using application/zip
instead, which is similar, and registered, but unsupported by all
implementations to date. The application/java-archive type is,
however, widely used in practice and has been in use for a long
time; for instance, the HTML 4 specification also uses it in an
example.
Unregistered media types should not be used except in an
experimental context, and Java is hardly an experimental
context. The Working Group has therefore contacted Sun
Microsystems and requested that they register the
application/java-archive media type. The commentor remains
unsatisfied on this point.
13. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'image/svg+xml charset parameter'.
The commentor asks for a charset parameter to be added to the
image/svg+xml registration document. This parameter has never
appeared in such a registration. Further, according to RFC 3023,
it would override the XML encoding declaration whether it was
present or absent. The TAG has explained, in "Architecture of
the World Wide Web, Volume 1," that this breaks Web Architecture.
A revision to RFC 3023 is in preparation that will align it with
"Architecture of the World Wide Web." The SVG media type
registration is consistent with drafts of the revised RFC.
14. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'Microsyntax definitions and schema'.
The commentor states that some non-terminal symbols in the latest
public draft are undefined. In some cases, such as 'string' or
'name' or 'content-type', implementors had already correctly
inferred the meaning. Nevertheless the remaining symbols have
been tracked down and defined.
The commentor was also troubled by the lack of a formal grammar
in RFC 2045. The SVG Working Group has requested that the
commentor address his comments to the RFC 2045 editors.
15. Björn Höhrmann registered a Formal Objection on 4 August 2006
regarding 'xml:id, id attribute, and id DOM attribute problems'.
The commentor considers the use of xml:id and id in SVG Tiny 1.2
to be "unsound and unlikely to be implemented." This opinion is
not shared by implementors, or indeed by participants in the XML
Core Working Group including the editors of the xml:id
specification. The Director feels that the CR period is the right
time to evaluate implementability of this feature.
The commentor also asks for an unusual CR exit criterion; that
regardless of how many implementations pass, a single failing
implementation is sufficient to block exit from CR. Such a
request is unprecedented and has the obvious drawback that a
skeleton implementation could be created and abandoned
specifically to block CR. The Director has chosen not to impose
the suggested exit criterion on the Working Group.
--
Chris Lilley mailto:chris@w3.org
Interaction Domain Leader
Co-Chair, W3C SVG Working Group
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG
Received on Thursday, 10 August 2006 14:17:29 UTC