Re: [SVGMobile12] QA WG review on your Last Call Document

On Thursday, May 19, 2005, 7:50:38 PM, Karl wrote:

KD> Dear SVG WG,

KD> This is a review of SVG Tiny 1.2
KD> http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/

This is a consolidated reply (parts have been replied to before, but
they are repeated in this response).

KD> Thank you for this nice piece of work.

Glad you like it. Thanks to your detailed comments on the previous
draft, this one is much improved.

KD> * Architecture of the World Wide Web and Conformance.

KD> [[[
KD> It is believed that this specification is in conformance with the Web  
KD> Architecture [AWWW].
KD> ]]] - http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/ 
KD> intro.html#AboutSVG

KD> Comment:
KD> 1. There's no link to AWWW
KD> 2. It's not possible to be conformant to AWWW (for now)
KD> [[[
KD> This document does not include conformance provisions for these  
KD> reasons: …
KD> ]]] - http://www.w3.org/TR/2004/REC-webarch-20041215/#about

KD> Maybe a better wording would be:
KD>      "It is believed
KD>      that this specification is in accordance with the Web Architecture
KD>      principles as described in AWWW"

We agree, have added the AWWW link to the references and have used your
suggested wording to reference it.

KD> * Markup of the Specification

KD> Comment:
KD> We would like to notice that the XHTML markup and the layout style  
KD> used for this specification is very clean and nice to read.

Thanks. There have been a few flaws noted, the references did not use
cite correctly and there were some comments on the IDL as well, but in
general we like the markup too.


KD> * Backwards compatibility

KD> [[[
KD> SVG Tiny 1.2 is a backwards compatible upgrade to SVG Tiny 1.1 .
KD> ]]] - http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/ 
KD> intro.html#defining

KD> Comment:
KD> How do you define backwards compatibility? In particular, do you  
KD> address deprecation? obsolete features?
KD> Backwards compatibility affects the various classes of products  
KD> (viewsers/authoring
KD> tools/interpreters...). So it would be very important to define all  
KD> these notions and tied them to each specific class of products.

We agree, and have separately addressed this by classes of product. The
intent here was to state that the language was backwards compatible. The
case for SVG 1.2 processors reading SVG 1.1 content is separately
addressed.

KD> * Reference to XML for DTD subsets

KD> [[[
KD> Note that in XML, there is no requirement to fetch the external DTD  
KD> subset and so relying on an external subset reduces interoperability.
KD> ]]] - http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/ 
KD> intro.html#defining

KD> Comment:
KD> Maybe you might want to give a link to the part of the XML  
KD> specification explaining that. Be careful to give a detailed  
KD> reference: XML 1.0 3rd edition, XML 1.1?

We agree and link to the XML 1.1 definition. While understanding your
point about specific versions, in fact in this instance this has not
changed from XML 1.0 first edition right through to XML 1.1. Its a key
difference from SGML.


KD> * Example entity.svg

KD> [[[
KD> <svg xmlns="http://www.w3.org/2000/svg">
KD> ]]] - http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/examples/ 
KD> entity.svg

KD> Comment:
KD> In the previous example, you define an SVG 1.2 Tiny document as  
KD> something starting with:
KD>      <svg xmlns="http://www.w3.org/2000/svg"
KD>          version="1.2" baseProfile="tiny" …

KD> Is your new example, still an SVG 1.2 Tiny document?

Unfortunately this example was edited to add an erroneous public
identifier just before publication; this has already been noted and was
incorrect. It now starts

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg [
    <!ENTITY Smile "
    etc etc

This is allowed by the XML specification.

Yes. The root element still has a local name of svg and a namespace of
http://www.w3.org/2000/svg - the preceding doctype declaration does not
affect that.


KD> * Space character for Macintosh HFS

KD> [[[
KD> It is recommended that SVG files stored on Macintosh HFS file systems  
KD> be given a file type of "svg" (all lowercase, with a space character  
KD> as the fourth letter).
KD> ]]] - http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/ 
KD> intro.html#mimetype

KD> Comment:
KD> It might be maybe a bit too much, but does it matter to know which  
KD> space character, for example giving the Unicode reference of the  
KD> space character?

The Unicode name for the character, which the manual of style recommends
to use, is 'space'. Macintosh HFS file types are restricted to ASCII so
there are no other space characters that could be confused with it. In
some ways it is a little much, since US-ASCII has exactly one space
character; we added the clarification about the code point, U+0020
anyway. http://www.unicode.org/charts/PDF/U0000.pdf I


KD> * Reference from CSS2

KD> [[[
KD> Examples include the 'background-image' and 'list-style-image'  
KD> properties that are included in both CSS and XSL.
KD> ]]] - http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/concepts.html

KD> Comment:
KD> Does it mean that a "background-image:" in an XHTML document calling  
KD> an SVG file must be rendered?

Its more complex than that, so as you question is stated the answer is
'no' because it has no conditions.

Our specification on the other hand imposes two conditions:

a) if the implementation can render SVG
b) if the implementation applies CSS to document-like markup such as
XHTML

then, if both conditions are met, yes, it must render the SVG as a
background image.

KD> I know that CSS2 doesn't define the format of images,

Correct.

KD>  but I'm not sure if SVG can impose a behaviour of
KD> CSS2.

It does not impose a behaviour on CSS2. It imposes a behaviour on SVG
implementations, which can already render SVG, if they are also CSS
implementations. The idea is that the SVG image format, if understood,
should be usable wherever any other image format is usable.

Imagine if an XHTML viewer allowed JPEG images in content but did not
allow them as background images, for example.

KD>  Though it seems you define that an XHTML/CSS viewer can also be
KD> an SVG viewer if it gives this possibility.

Yes, a viewer that rendered SVG but only allowed it as a background
image would fall into the product class of SVG viewer. It would be an
unusual case, and there would be no reason for such an implementation to
prevent display of foreground SVG images apart fro a perverse desire to
be difficult, but in terms of conformance yes it could be a conformant
viewer.

KD> * SVG inclusion of different versions.

KD> Comment:
KD> What should be the behaviour of a User Agent when for example an SVG  
KD> 1.2 document calls an SVG 1.0 document?

Since SVGT 1.2 content is a superset of SVG Tiny 1.1 the behaviour is
well documented there. For other cases (Full in a Tiny viewer) the
behaviour regarding unknown elements and attributes is described in the
specification in section D.5.1 Conforming SVG Interpreters.


KD> * Discard elements
KD> http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/ 
KD> struct.html#DiscardElement

KD> Comment: SVG 1.2 Tiny gives the possibility to discard parts of the  
KD> SVG animation. I can see the benefits of it. I was wondering what's  
KD> happening when someone links to a discarded part from outside. Does  
KD> the discard mechanism break the URI-references?

Yes. If it is discarded it is gone, the same as if a script had deleted
it.

KD> * Typo Instanced?
KD> [[[
KD> Any 'g' or graphics element is potentially a template object that can  
KD> be re-used (i.e. "instanced") in the SVG document via a 'use' element.
KD> ]]] - http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/ 
KD> struct.html#UseElement

KD> Comment: In my dictionary "to instance" is equivalent to to cite

Instantiation has a more technical meaning in programming, which is
perhaps not covered in a more general dictionary. We have changed this
to say 'instantiated' rather than 'instanced', which is the more common
usage.


KD> * Media Type for image
KD> [[[type = "<media/type>"
KD> A hint about the expected Internet Media Type of the raster image.  
KD> Implementations may choose not to fetch images of formats that they  
KD> do not support.
KD> ]]] - http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/ 
KD> struct.html#ImageElement

KD> Comment: That's good you said it was a hint. It might be good to  
KD> remind people that HTTP headers have always priority.  An SVG viewer  
KD> MUST NOT ignore the HTTP headers when given.

Hey, three years on the TAG had to rub off somehow. We also now cite the
TAG finding and WebArch as well.


KD> * Common attributes - Typo?
KD> [[[
KD> class = list
KD> ]]] - http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/ 
KD> struct.html#Core.attrib

KD> Given without double quotes, when the others have quotes.

Thanks, we fixed that typo.

KD> * Styling Properties
KD> [[[
KD> SVG shares many of its styling properties with CSS [CSS2] and XSL [XSL].
KD> ]]] - http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/ 
KD> styling.html#SVGStylingProperties

KD> Comment: s/CSS [CSS2]/CSS 2.0 [CSS2]/
KD>      what will happen when CSS 2.1 is coming out?

Thats a very good question. It seems like a good last call comment on
CSS 2.1, in fact. CSS 2.1 is not exactly a second edition of CSS2, so it
does not clearly supercede it; it also deletes substantial parts of the
CSS2 spec and has many detailed changes compared to CSS 2.0 so it does
not seem possible to conform to both CSS2 and CSS 2.1 at the same time:


#foo > #bar[x=toto] { color: red }

<a xml:id="foo">
 <b xml:id="bar" x="toto" style="color:green">Help!</b>
</a>

this will be red in CSS2 (specificity of 210 is greater than 100) and
green in CSS 2.1

KD> It seems the CSS 2.1 Spec is intended to replace the CSS 2.0
KD> specification.

It seems that it is intended to partially replace it, while leaving
other parts not replaced, all the while stating that no erratta will be
published on it and leaving other specifications that normatively
reference CSS 2.0 in a sticky position.

KD> Does that mean that the implemeners MUST stick to CSS 2.0 Same kind
KD> of comment for XSL. Precise the version.

For CSS2, we are precise about the version. CSS 2.0

For XSL, either 1.0 or 1.1 can be used. The reference is informative in
both cases.

(We made this last call comment to CSS 2.1, but have not had a response
back yet from the group).

SVG, like XSL, depends on parts of CSS2 that have been removed in CSS
2.1, apparently because common CSS+HTML implementations do not use them.
We therefore need to link to CSS 2.0 specifically.

KD> Same kind of comment for XSL. Precise the version.

KD> ***General*** Through your whole document, give precise references to  
KD> the technology. Generic names as HTTP, XSL, CSS, etc. are misleading  
KD> for the implementers who might understand one particular version of  
KD> the technology which is the one you had in mind. One of the most  
KD> common mistakes is XML reference. which version? XML 1.0, XML 1.0 3rd  
KD> edition, XML 1.1.

We require processors to conform to XML 1.1 and allow content to be
either 1.0 or 1.1. We have appropriate links to dated version of these
specifications.


KD> * Coordinate System Transformation:
KD> http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/ 
KD> coords.html#EstablishingANewUserSpace

KD> Comment: Illustrations of matrix transformation. WAI people might  
KD> argue that the images are not accessible, maybe a link to a mathml  
KD> file with the equation might be useful.

We agree and have replaced these with object elements pointing to
MathML; the PNG images are used as a fallback for user agents tha do not
support MathML.


KD> * Events zoom authoring tool?
KD> http://w3c.test.site/TR/2005/WD-SVGMobile12-20050413/interact.html

KD> SVG 1.1 "SVGZoom"

KD> SVG 1.2 {"http://www.w3.org/2001/xml-events", "SVGZoom"}
KD> SVG 1.2 {"http://www.w3.org/2001/xml-events", "zoom"}

KD> Comment: What an authoring tool should do when loading an SVG 1.1  
KD> document and saving it as an SVG 1.2 document? Convert SVGZoom to zoom?

Yes. Along with changing some other things like version, baseProfile,
removing the doctype etc.

However, it seems there are some issues with namespace of events, we
have now clarified that unqualified events are in the XML Events
namespace.

KD> * Implementation Requirements
KD> http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/implnote.html

KD> Comment: You might want to precise what are the classes of products  
KD> you address in this section.
KD> User Agents, bots, authoring tools, etc.

We agree and have clarified the class of products addressed here,
primarily SVG viewers. (bots are not a class of product listed in our
conformance section).

KD> C.3.1 Example

KD> Comment: Where is the example?

The markup that would have included it was commented out. This is now
fixed.

KD> D.1 Introduction
KD> Comment: Typo "Software that writes SVG (including authoring tools  
KD> and severs)"  -> Servers

fixed.

KD> E. QA ICS
KD> http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/qa-ics.html

KD> Comment: The QA WG is very grateful to see the inclusion of the ICS  
KD> in your specification. Without knowing it, you have used an  
KD> incomplete version of the ICS, which has been republished since.  We  
KD> took the freedom to create a new ICS for SVG Tiny 1.2, you will find  
KD> it at
KD>      http://www.w3.org/QA/WG/2005/05/svg-tiny-12-qa-ics
KD> Feel free to use it and adapt it to your needs.

Thank you, we have done so. We modified it to note that we do have a
glossary in fact.

KD> L. Media Type registration
KD> http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/mimereg.html

KD> [[[
KD> Person & email address to contact for further information:
KD> Dean Jackson, (dean@w3.org).
KD> ]]]

KD> Comment: In the tradition of IETF, having the address of someone  
KD> seems the way to go for registering media-type, but I was wondering  
KD> if a more generic address would be better even if redirected for the  
KD> time being to Dean's email.  Something like "svg-contact at w3.org"

We agree. It now says

Dean Jackson, Chris Lilley (member-svg-media-type@w3.org).

Many thanks for your detailed and useful comments, please let us know
shortly if they do not address your concerns.

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

Received on Thursday, 3 November 2005 13:11:16 UTC