- From: Cyril Concolato <cyril.concolato@enst.fr>
- Date: Mon, 13 Oct 2008 13:03:47 +0200
- To: www-svg@w3.org
Dear SVG WG Member, Please find below a set of comments on the 15 September 2008 Last Call Working Draft of SVG Tiny 1.2. * Typos: - In "Status of this document", it says "This is *a* the 15 September 2008". - In "5.7 The 'image' element", it says "(e.g. *is* is outside the initial document viewport)" - In "7.8 The 'viewBox' attribute", it says "must *be* be mapped" - In "15.7 Processing inline executable content", it says "the content *must ignored* and no further processing takes place." - check case of <QName> vs <qname>. - The type '<ListOfStrings>' is used in the attribute table instead of '<list-of-strings>' in Section 4. * General editorial The lacuna value wording is not used for all attribute definitions for example transform, viewBox ... * Section "Status of this document" It says that the CR exit criteria is "two interoperable implementations for each test in the SVG Tiny 1.2 test suite". Is it two implementations, each passing all tests; or for each test, two passing implementation ? * Section "1 Introduction" I think this text could mention that audio playback is also possible in an SVG User Agent. * Section "1.6 Definition" Generally, I think the definition of bounding box is too long to be in the definition sections, it makes the definition section hard to grasp. Additionally, the definition of bounding box explicitely excludes some stroke attributes but not others like stroke-dasharray, join, cap. I suggest adding all stroke attributes. This definition says: "For curved shapes, the bounding box must enclose all portions of the shape along the edge, not just end points, but must not include control points for curves that are not within the shape itself." The 'must not' requirement should be changed to a 'should' because depending on the curve and depending on the precision of the implementation (fixed point), it may be impossible to make a bounding box that does not include the control point. Could you clarify the meaning of the following sentence especially for the defs element? "Elements which do not partake in the rendering tree (e.g. elements in a 'defs' element, elements whose 'display' is none, etc.), and which have no child elements that partake in the rendering tree (e.g. 'g' elements with no children), shall not contribute to the bounding box of the parent element, but must return a bounding box for the sake of calculating their own geometry." What does the bounding box of a defs element 'must return (...) for the sake of calculating [its] own geometry.'? There are two related definitions: canvas and SVG canvas. Do you really need 2 different definitions? Where in the spec do you use canvas with a different meaning than SVG canvas ? It is not clear how these terms are used in the spec. For example, we find: target canvas, current canvas, intermediate canvas, resulting canvas, background canvas, and temporary video canvas. The definition of "graphics referencing element" misses the foreignObject element, no? * Section 4 "Basic Data Types" The id and xml:id attributes use the <ID> type in the spec but the <ID> or <NCName> types in the attribute table. In the definition of the <QName> type, a sentence says: "the default namespace is *not* used for unprefixed names". Could ou provide an example showing what this means ? The spec text gives the following definition for the target attribute of the 'a' element: target = '_replace' | '_self' | '_parent' | '_top' | '_blank' | "<frame-target>" but the attribute table says: target = '_replace' | '_self' | '_parent' | '_top' | '_blank' | <XML-Name> The spec text for handler says: ev:event = "<string>" but the attribute table says: ev:event = <XML-NMTOKEN> The spec text for listener says: event = 'Event Identifier' but the attribute table says: event = <XML-NMTOKEN> * section 5.1.2 The 'svg' element The syntax for baseProfile is ambiguous, it says: baseProfile = "profile-name" But "profile-name" is not allowed value. Replace it with: baseProfile = "none" | "full" | "basic" | "tiny" * section 5.2 The 'g' element In general, the way "attribute definitions" are given is confusing. For example, if one does not understand RNG (and dig into all RNG snippets), it will think the g element only has the focusable attribute and the navigation attributes Also, the general syntax sometimes is confusing: for example: preserveAspectRatio = "[defer] <align> [<meet>]" should rather be something like: preserveAspectRatio = ["defer"] <align> [<meet>] There are several examples in this case. * Section 5.5.2 The last sentence of Section 5.5.2 seems to be an editing mistake: "If the appears both 'title' and at most one 'desc'" Could you fix it ? * Section 5.6 The following sentence is unclear: "If an event listener is registered on a referenced element, then the actual target for the event will be the SVGElementInstance object within the "instance tree" corresponding to the given referenced element." What is the difference with the next paragraph ? In this section, the spec explain the transfer of attribute from a use element to an hypothetical g element. In this explanation, why is the 'xlink:href' of a use element transfered to the generated content? What is the purpose? I think there is an editing mistake in this section. It says: "except for resolution of relative IRI references as noted above and until the referenced elements are modified. Note also that any changes to the used element are immediately reflected in the generated content. " The first sentence is incomplete. Could you add a clarification explaining what happens to id and xml:id attributes in the deep-cloned tree? For example, between examples 05_13.svg and 05_14.svg, ids have been remove. Please explain also what happens to xlink:href attributes especially that internal references to the cloned tree are replaced by 'scoped' references. Example "image-use-base.svg" contains errors. The use element does not have width and height attributes. According to the example image-use-base.svg, the content of xml:base is not simply transfered to the "generated 'g' element" but the xml:base is resolved before transfering in it to the generated 'g' element. Could you clarify this process? * Section 5.7 The 'image' element In the first sentence, the words "complete document" seems to imply that an (XML) document can be referenced from an image element while the second sentence says the opposite. Could you rephrase ? The attribute definitions for the 'image' element does not use the usual 'lacuna value sentence' for x, y, width and height. Could you rephrase the following sentence? It does not look like a correct sentence: "For optimizing download time by requiring a particular content format authors are encouraged to use 'requiredFormats', instead of 'type'." * Section 5.8 Conditional Processing: The specification says: "Conditional processing attributes do not affect the processing of all elements. They can be specified only on graphics elements, container elements, text content elements, descriptive elements, timed elements and the 'foreignObject' and 'discard' elements. A conditional processing attribute on any other element does not affect whether that element will be processed." Could you add an explanation about what happens to elements (script, handlers, animations, listeners) inside a container element which has a conditional processing attribute evaluated to false? * Section 7.1. Coordinate Systems, Transformations and Units Introduction Could you add a clarification about when the canvas negotiation happens? I think it happens upon parsing the start tag of the SVG root element but this is not clear. * Section 5.9.1 The 'externalResourcesRequired' attribute What is the rationale behind the sentence: "If a node enters the error state then the document enters the error state and progressive rendering stops." Is this behavior compatible with traditional HTML processing? * Section 5.9.3 The 'prefetch' element Could you add a note explaining the relationship between the eRR attribute and the prefecth element, especially when the prefetch element points to a 'g' element in the current document? The definition of mediaSize says "Defines how much of the media to fetch in bytes as a function of the file size of the media." What is the function ? I suggest removing the last part of the sentence since percentage is not allowed. Similarly for mediaTime. Example prefetch02.svg uses a UTF-8 coding but the prefetch elements use UTF-16. Is it normal? * Section 5.10.1 Attributes common to all elements The use of the new attributes (rel, rev,...) is not clear. Could you mention if ARIA is also meant to be used in each of rel, rev ... attributes? * Section 7.10 Establishing a new viewport I don't understand the note about clipping and overflow. The overflow property is not supported in Tiny 1.2, so it means that 1.2 player will ignore any overflow attribute. * Section 11.10.5 The 'buffered-rendering' property What is the relationship between SVG T 1.2 'buffered-rendering' attribute and the SVG Full 1.2 rendering hints (http://www.w3.org/TR/2004/WD-SVG12-20041027/painting.html#sprites) cache/static/snap ? * Section 12.1.1 Media timeline and document timeline The specification says that media elements which are loaded only when they become visible for the fist time may introduce delay. In that case, what document time corresponds to the beginning of the media timeline ? The begin value or the begin value + the delay ? Is it correct to say that assuming timelines are locked, then the UA has to adjust playback to cope with the load time (similarly to a timelineBegin=onStart)? Replace: "the value of the 'syncBehavior' attribute are replaced from the default one ('default', interpreted as 'locked' in that case since the 'syncBehaviorDefault' is not specified) to 'independent'." with: "the value of the 'syncBehavior' attribute are set to 'independent'." The current wording 'interpreted as locked' is ambiguous. The actual interpretation of 'default' is implementation specific and the spec seems to imply that it should be interpreted as locked all the time. Could you clarify what the exact locking behavior is ? If a media timeline is locked to the document timeline and if the video is paused, what happens ? Is the document timeline locked? The xlink:href of audio and video says: "When the value of the attribute is animated or otherwise modified, if the media play time can be controlled, then the media timeline is restarted. " First, the term 'play time' is not defined. I suggest changing "media play time" to "media timeline". But if the media timeline is locked, changing the xlink:href to a new value, without changing the begin value, will not restart the media timeline (or it will restart it but at time = the document time when the change happened). What happens if the media timeline cannot be controlled? The specification should say what happens when a video/audio element points to a file or a set of streams containing multiple audio tracks (english and french, or AAC and AC3) or multiple video tracks. * Section 13.8 Event dispatching The following 2 sentences seem contradictory. According to the first sentence, there is always at least the root as a target. Could you clarify? "If the user agent cannot find a graphics element or SVGElementInstance object to be the target object (e.g., the pointer event occurs over the viewport background), then the user agent must set the target object to be the rootmost 'svg' element." and "If there is no target object, the event is not dispatched." * Section 14.1.6 Externally referenced documents The section is quite hard to read and it's not easy to understand the difference between the processing of primary and resource documents. For example, instead of copy/pasting the "conceptual processing model" of primary documents for resource documents could you just give one unique paragraph? Could you highlight in the text the common points and differences? For example with the following structure definitions: - primary document: referenced as a whole (no fragment). In SVG Tiny 1.2, it only concerns 'a', 'animation' and 'foreignObject' (as per restriction) - resource documents: referenced using a fragment identifier. In SVG Tiny 1.2, it only concerns 'use' and 'foreignObject' (as per restriction) common points: - processing is that events are fired, scripts are executed, ... differences: - resource documents are loaded only once per primary document - primary documents may be loaded multiple times Could you also answer the following points: - What about "externally referenced media" ? Does a primary document maintain a dictionnary of media resources? If a video is refered twice in the scene does this lead to two different ressources? - What about externally referenced scripts ? * Section 15.2.1 Script processing Can you clarify the sentence "If a 'script' element falls outside of the rootmost 'svg' element" ? When does it happen ? Is it only in the case of DOM creation ? Can you give examples ? * Section 16.2.7 Paced animation and complex types Since a polygon is a simple kind of path, it seems strange to allow paced interpolation of path but not of polygons. Could you explain why the group reached this conclusion ? * Section A.8.12 TraitAccess The specification says: "For 'required' attributes, there are two cases: * i) The document is in error, if this attribute was not present at the time of loading. * ii) When using the uDOM API, the specified lacuna value (in parenthesis) must be used." Could you explain what the first bullet means ? What is a 'required' attribute? The lacuna value is used when an attribute is not specified. Why would the document be in error ? Could you also explain what is the relationship between exceptions thrown in a script, and the state (error or not) of the script node (and of the document). * Section J.2 Specific feature strings The feature string for core attributes should include the newly added attributes (rev, rel...). Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Received on Monday, 13 October 2008 11:05:47 UTC