- From: Chris Lilley <chris@w3.org>
- Date: Thu, 9 Jun 2005 18:20:27 +0200
- To: Karl Dubost <karl@w3.org>
- Cc: www-svg@w3.org
On Thursday, May 19, 2005, 8: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/
Hi Karl. Here are some comments on those parts of your review that seem
to be straightforward and can be answered immediately.
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
We should fix that, but (as you note below) it would need to be an
informative reference.
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"
I agree that this is much better wording. Hay, maybe that is why QA
suggests specs should have language for other specifications claiming
conformance (or in this case, accordance). Or maybe ".. is compatible
with the Web Architecture ...." or ".. is consistent with ..."
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?
I agree that this should be separately addressed by classes of product.
The intent here was to state that the language was backwards compatible.
KD> In particular, do you address deprecation? obsolete features?
Yes (there are no deprecated elements and no obsolete features, as noted
in the conformance to QA Spec Guidelines section).
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.
Yes, agreed. We will address different classes of product separately
here.
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.
Yes.
KD> Be careful to give a detailed
KD> reference: XML 1.0 3rd edition, XML 1.1?
This has not changed from XML 1.0 first edition right through to XML
1.1. Its a key difference from SGML. But we will provide a dated
reference so that the link does not break in future.
KD> * Example entity.svg
Unfortunately this example was edited to add an erroneous public
identifier just before publication; this has already been noted and was
incorrect. It should actually start
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg [
<!ENTITY Smile "
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?
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'. We can add the code point, U+0020 but AFAIK
Macintosh HFS file types are restricted to ASCII so there are no other
space characters that could be confused with it. We will add the
clarification anyway.
http://www.unicode.org/charts/PDF/U0000.pdf
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> ]]] -
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
KD> 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 SVG 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) I believe
it is specified, but we will check and get back to you.
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 should probably say
'instantiated' rather than 'instanced'.
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.
Hey, three years on the TAG had to rub of somehow.
KD> 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.
We could usefully link to the TAG finding and the AWWW here.
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.
Will check.
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
KD> 2.1 Spec is intended to replace the CSS 2.0 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
KD> mean that the implemeners MUST stick to CSS 2.0
KD> Same kind 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.
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.
Yes, we are going through and fixing this for normative references. In
some cases 9eg for Unicode) we also say that future compatible versions
can be used (as recommended in this case by charmod, for example).
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.
I agree that oimages by themselves are not sufficient for equations. It
would be much better if mathml was supported, yes. We will look at
longdesc as a way to explain the equations. MathML might be useful
there, but also might confuse screen readers so we will seek expert
guidance.
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?
KD> 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, as
seen in other threads, so we may need to clarify this.
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.
I agree. (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. Will fix.
KD> D.1 Introduction
KD> Comment: Typo "Software that writes SVG (including authoring tools
KD> and severs)" -> Servers
yup
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.
Thanks for bringing this to our attention. We are happy to use the
latest version .
KD> 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.
That is very kind. We appreciate the gesture, and will take another look
at the good practice notes you added there.
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"
(I see Dean already responded to this, and agree)
Thanks once again for your detailed and helpful review.
--
Chris Lilley mailto:chris@w3.org
Chair, W3C SVG Working Group
W3C Graphics Activity Lead
Received on Thursday, 9 June 2005 16:20:39 UTC