Re: [1.2T-LC] Comments on Last Call WD of SVG T1.2

Dear Chris, all,

For some reasons, I have not received your email related to ISSUE-2130. I just saw it in the archives.

Concerning xml:id and id, if I understand correctly, 'id' is always of type <ID>, while 'xml:id' is of type <ID> if there is no 'id' attribute on the element, otherwise it is of type '<NCName>'. Is that correct? Could you add a note ? Or change the attribute definition to:
 xml:id = "<ID> | <NCName>"   

For the <QName> comment, I'm satisfied with the proposed sentence. It is clearer. I'm also satisfied with the others datatype issues.

Thanks,

Cyril


Cyril Concolato a écrit :
> 
> 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 Thursday, 30 October 2008 16:21:48 UTC