SVG Tiny 1.2 Disposition of Comments

13 August 2004 Last Call Working Draft

This is the Disposition of Comments for the 13 August 2004 first Last Call of SVG 1.2. Significant changes were made to the SVG Tiny 1.2 specification, to make it clearer and easier to read with no dependencies on other SVG specifications. As a result of these changes, instead of moving to Candidate Recommendation, a second Last Call is being issued. This document lists, for information, the comments recieved on the first Last Call specification and the extent to which we believe they have been addressed in the second Last Call.


AgreeThe commentor and the WG agree on the comment, and if necessary the specification has been altered or clarified to bring it into line with what the commentor requested.
DiscussThe comment resulted in some discussion, but no change seemed to be asked for and none was made.
CompromiseThe commentor and the WG compromise on the comment; the WG has explained why they feel the sugested changes woud not be an improvement, or have drawbacks outweighing the gain, or are too hard to implement. Please review the second Last Call specification and check that it is better now.
DisagreeThe commentor and the WG compromise on the comment, the WG have explained their reasoning, and the commentor has stated they are unsatisfied. Please review the second Last Call specification, and submit a comment on it if required.

Comments and their resolution

T001 Multiple Pages in SVG 1.2 + Hyperlinking
Jon Phillips

We agree that this type of hyperlinked functionality is useful Craig Northway explained how to do this with the 'use' element to which Jon replied Excellent, this is exactly the type of reply I was hoping for

T002 Typo in SVG tiny 1.2 draft
Elliotte Rusty Harold

We agree, and have fixed the typo.

T003 [SVGT12 Comment] Comments from Andrew Girow
Andrew Girow via Chris Lilley

The specification and the IDL were out of sync; this has been corrected. The IDL was correct; the problems you saw were from the incorrect html version of the interface definition. The actions on getting and setting color traits, and in particular the way that computed rather than specified values are returned, was explained in this email. The commentor did not feel comfortable with the explanation.

T004 [SVGT12 Comment] Comments from Andrew Girow
Andrew Girow via Chris Lilley
2. SVGSVGElement

The documentation on currentRotate has been updated to precisely define what it means and its relation with the currentScale and currentTranslate members, as was explaind in this email.

T005 [SVGT12 Comment] Comments from Andrew Girow
Andrew Girow via Chris Lilley
3. Fixed Points vs Float Points

Conformant impementations may use fixed point internally; for simplicity the interfaces are defined in terms of float. The tradeoff, and the reason for doing this (JSR226 compatibility) was explained in this email The specification has been clarified to indicate this.

T006 [SVGT12 Comment] QA Review - 20040813 version
karl Dubost, QA WG

We agree with the general thrust of this comment and have altered the specification substantially to take it into account. There is now a much better conformance appendix. There is also a form showing in detail how the specification meets the QA specification guidelines. The specification now has numerous examples. The classes of conformant product are clearly described.

T007 [SVGT12 Comment] from Device Independent Working Group
Rhys Lewis, DI WG

We agree that the dependency was a problem and made the specification hard to review. This has been corrected in the second Last Call specoification for SVG Tiny 1.2 which is now a standalone specification.

We look forward to reviewing the DISelect specification and thany you for bringing it to our attention.

T008 [SVGT12 Comment] SVG Tiny review
by way of Al Gilman, WAI PF WG
1. <desc> is absent. This needs to be put back.

We agree the spec needs to have it, but it is already there. The reviewer was mistaken, see Jim Ley's response

T009 [SVGT12 Comment] SVG Tiny review
by way of Al Gilman, WAI PF WG

2. <title> is absent. This needs to be put back.

We agree the spec needs to have it, but it is already there. The reviewer was mistaken, see Jim Ley's response

T010 [SVGT12 Comment] SVG Tiny review
by way of Al Gilman, WAI PF WG
3. How are they addressing closed captioning for video? Where is support for SMIL?

Closed captioning is problematic. If an individual video format supports it, SVG can support it as part of supporting that format or codec. We have asked the SYMM WG for a way to address individual components (multiple language audio streams, different aspect ration video streams, closed captioning) in a container format video stream. It is possible for a video authoring tool to generate SVG Tiny that uses video elements for video, audio elements for separate synchronized audio, and SVG text and animation elements for closed captioning. However, currently most content is not authored like that.

Also, when the TimedText WG has produced its deliverables for a delivery format we will look into integration.

The SMIL 2.0 specification has a normative reference in SVG Tiny 1.2.

T011 [SVGT12 Comment] SVG Tiny review
by way of Al Gilman, WAI PF WG
4. Where do the specify animation control?

This is defined by SMIL 2.0. Animation control is at the granularity of time containers and timed media objects. Thus for example in SVG Tiny 1.1 it is possible to pause a video element because it is a timed element. This has been clarified in the second last call of SVG Tiny 1.2.

T012 [SVGT12 Comment] SVG Tiny review
by way of Al Gilman, WAI PF WG
5. Support for text access Why is tref not available for <text>

We have considered this request, and the feedback from implementors is that tref makes text in SVG Tiny 1.2 too hard to implement. We recognize that there are some accessibility advantages to using tref, but there are also some drawbacks as noted in Jim Ley's response who argued that tref was in some cases an accessibility burden depending on how it is used. On balance we have decided not to add tref to the SVG Tiny 1.2 specification.

T013 [SVGT12 Comment] SVG Tiny review
by way of Al Gilman, WAI PF WG
6. <g> is absent. This needs to be put back. This is used as a means of defining structure and corresponding text equivalents.

We agree the spec needs to have it, but it is already there. The reviewer was mistaken.

T014 [SVGT12 Comment] SVG Tiny review
by way of Al Gilman, WAI PF WG
7. Where is XForms support? Is this expected as an add on? XForms has a lot of accessibility features through declarative markup.

XForms Basic is an interesting specification and starting to see implementation. It is not possible to require XForms support from all SVG Tiny 1.2 implementations at this stage. Combining multiple namespaces, such as SVG and XForms, is in the scope of the CDF Working Group and the SVG WG is tracking this closely. Combined namespace implementations are possible today, but would lack the framework that CDF is providing. In summary, it is not required but nor is it precluded. Yes, currently this would be an add-on.

T015 [SVGT12 Comment] SVG Tiny review
by way of Al Gilman, WAI PF WG
8. Support for meta information (xhtml2 meta module)

SVG already has the metadata element since version 1.0; this can contain arbitrary well formed content, such as RDF/XML. SVG Tiny 1.2 includes the metadata element. Contrary opinions saying the proposed solution was not suitable were expressed in this message and also this one. On balance we have retained our existing metadata approach. Tracking GRDDL would allow this approach to be strengthened in the future.

T016 [SVGT12 Comment] ACCESS comments on SVG Tiny 1.2 last call WD 040917
Yamakami, T. , Access
(a) Recommendations

SVG Tiny 1.2 is not mobile specific. Like SVG Tiny 1.1, it can be and has been implemented on desktop systems as well as mobile ones. SVG Tiny 1.2 does not produce divergence between desktop and mobile - in the new specification it is made much more clear that SVG Tiny1.2 is the core of the SVG 1.2 specification.

We agree that there are a wide variety of video codecs and that it is not, unfortunately, currently possible to require that all implementations support one or more standard ones because of the lack of good, mature, royalty-free codecs. However, there is substantial demand for video on mobile devices so we decided to include the functionality.

The CR exit criteria will include a requirement of implementability on a constrained mobile platform, as did the SVG Tiny 1.1 specification. We agree on the importance of this. We are seeing substantial implementation already.

T017 [SVGT12 Comment] ACCESS comments on SVG Tiny 1.2 last call WD 040917
Yamakami, T.
(b) Minor Comments

(b-1) The WG agree that the dependency on SVG 1.2 Full was problematic. The entire specification has been refactored to remove this dependency.

(b-2) The WG does not believe that any specification, no matter how limited, can be understood in 10 minutes. However, we believe that the current specification is significantly easier to understand than the previous version, both for implementors and for content authors.

(b-3) The WG agrees that features such as text wrapping should be specified such that they apply to many languages not just a few. It was possible (but difficult) to determine from the first Last Call document that text wrapping was in fact specified for languages such as Japanese where there are no spaces between words. It is much easier to see this now in the second Last Call draft.

T018 Comments to SVG 1.2 spec
Angelo Borsotti, Alcatel

We agree that work such as that done by the CDF Working Group is badly needed.

Some of the network interface functionality you request is already in the specification, please see the Connection interface.

We are thankful for your comment, though some of it applies to SVG 1.2 Full rather than Tiny.

T019 Animating clips (tracks in SVG?)
Mark McKay

The SVG WG agrees that the ability to refer to animation clips and to repeat them is useful. We have added the animation element (from SMIL 2.0) in the second Last Call working draft, which allows animations to be defined - in an external file, or internally - and then referenced (perhaps multiple times) with control over repeats, starting and stopping each instance. We thank you for your comments and would be interested to see an implementation of this functionality in your Salamander SVG player.

T020 mouse alternatives
Jonathan Chetwynd

The SVG WG agrees that a keyboard can be used instead of a mouse or other pointing device. A response from Doug Scheppers also suggested multi-way key navigation, and this has been added to the specification.

T021 Gradients/SVG image
Christophe Gillette, Motorola
1) default values in percentages

The SVG WG agrees that percentages had been removed from gradient stops but not from other places in gradients such as the deault values for x1 etc. This has now been fixed.

T022 Gradients/SVG image
Christophe Gillette, Motorola
2) units on top svg referred to by image

SVG Tiny 1.1 did not allow an image element to refer to an SVG image. The first Last Call of SVG Tiny 1.2 did allow this, and had the ambiguity you describe. In the second Last call, the image element is once more restricted to only referring to raster content, not SVG. The animation element can point to an SVG document or an SVG fragment, and the viewport behaviour in each case is described as is the handling of x,y,width and height attributes on the referenced SVG. The procedure for establishing viewports has been clarified.

T023 SVG 1.2 tiny
James Bentley, Guideworks TV
Why is tiny required to support circle and ellipse

SVG Tiny 1.1 had circle, ellipse, and (rounded) rectangle so for compatibility, SVG Tiny 1.2 has them too. A clear difference can be seen in the ease with which the radius of a circle, or one of the radii of an ellipse, can be animated when compared to the multiple synchronised animations required to simultaneously animate the x, y, width, height, rx and ry attributes of a rounded rectangle that looks like an ellipse.

T024 RE: SVG 1.2 tiny
James Bentley, Guideworks TV
Should SVG tiny require that attribute values be enclosed in double-quotes?

We agree that attribute values require double (or indeed single) quotes around them. This is not optional - it is required by XML well formedness.

T025 RE: SVG 1.2 tiny
James Bentley, Guideworks TV
gzip is required in Tiny?

Yes, gzip is required in Tiny. We have clarified the specification.

T026 SVGT1.2/gradients question
Christophe Gillette, Motorola
no transformation on gradient so no elliptical radial gradients? spec is unclear

Your deduction is correct; we agree this was unclear and have clarified the specification.