- From: Cyril Concolato <cyril.concolato@enst.fr>
- Date: Fri, 05 Nov 2004 10:48:03 +0100
- To: www-svg@w3.org
Dear SVG WG, So far, we have reviewed only parts of the WD (chapters 5, 7 and 8) and would like to make some comments on it. Other comments may follow. Chapter 5: Multiple Pages ------------------------- General Comment: It seems to us that most of the features of the page/pageSet elements can be emulated using g, set to animate the display, streamedContents on g. Our understanding is that the advantage in defining these elements is that it allows the user agent to easily identify the pages and provides a mechanism to go from one page to another. We believe such a sentence could be useful in the specification to understand and guide the author. Editorial Comments: * Definition of page: The second sentence (The "ordered list of elements ...") seems to be a definition of pageSet and not of page. * Typo: "The pageSet and page elements faciliate streamed animation" -> "The pageSet and page elements facili_t_ate streamed animation" "pageSeq" -> "pageSe_t_" Technical Comments: 1) Scoping and discard Rules: The mechanism which defines the scoping rules on the page elements and how its content may be discarded seems unsufficient for important applications (cartoons, slide presentations). The three examples below illustrate such applications. - Example 1: Cartoon Imagine a long cartoon sequence made of several pages. Usually in cartoons, many elements are reused in many pages but not all. With the current scoping and discard mechanisms, it is impossible to discard these elements, because either they would have to be global or repeated in all the pages. - Example 2: Navigation Consider the following example: Page 1 contains a rectangle and a circle. A click on the rectangle displays page 2. A click on the circle jumps to page 3. The rectangle and circle are usefull only in the display of page 1 but, according to the scoping, they have to be global to handle the beginning of page 2 and 3. If the scoping rule was relaxed, an explicit discard could be used after page 1. - Example 3: Reuse of pages: Consider the following example: <page id="page1">...page 1 content ...</page> <page id="page2"><use xlink:href="page1"></page> This case which is very frequent in long presentations (power-point like) seems to be disallowed. So a way to do this with the current draft would be the following: <defs> <g id="page1content">...page 1 content ...</g> </defs> <page id="page1"><use xlink:href="page1content"></page> <page id="page2"><use xlink:href="page1content"></page> Again, this leads to the global definition of all the content of the page 1. This is highly inefficient. 2) How to display an object on top of all the pages ? It is not allowed to place objects after the last page end tag and before the pageSet end tag. Proposal: allow SVG elements after the last page end tag and before the pageSet end tag. 3) Can there be several pageSet elements in an SVG document ? Seems no since nothing can appear between the pageSet end tag and the SVG end tag and since only pages can be in pageSet. => Proposal: Clarify the fact that only ONE pageSet element is allowed in the document. Consequence: An SVG document using pageSet becomes different from another SVG document. It implies a particular timing model and the rendering could be improved for this type of content. So, identifying easily this kind of document is important and not possible currently. => Proposal: Mandate that the pageSet element is the first and only children of the svg root. All the the other SVG elements should be placed before the first page or after the last page. This way, the SVG viewer can easily determine that the document has to be treated in a special way (possibly using streaming). 4) Timing and pages: Example: Consider an SVG document containing a global animation of a rectangle during 10s and a pageSet with 2 pages: page 1 lasts 5s, page2 lasts 5s. Now imagine that the user, viewing page 1, presses page down. Question: What happens to the animation of the rectangle ? In other words, how is the pageSet timeline linked to the document timeline. What is the relationship between the pageSet timeline and the document timeline ? 5) Clarify the last paragraph: "Once this example has been played and the begin and end times resolved, seeking to a page will not reset these values. The element state will reset when the parent time container repeats or restarts." What happens in the following scenario: The user has clicked quickly (after 0.1 sec) on all pages to reach page 10. Once page 10 is viewed, the user seeks back to page 5 (using pageUp). How long will page 5 be displayed ? The fact that the ending of the page is resolved forever (until restart or repeat) seems to contradict the SMIL animation specification. The handling of begin and end in SMIL uses a list of interval in which an instance of the unresolved values is kept even if the interval values have been resolved once. Chapter 7: Streaming -------------------- 6) General Comment: There seems to be a strong relationship between streaming and progressive rendering in the WD. A paragraph clarifying this relationship is needed. 7) "Streamed Content" : What is the definition of this term ? What is the notion of streaming ? What is an SVG stream ? We believe it is important to define a streaming model. Such a model should define what is the stream, what it is made of, the timing associated to the parts of the stream (presentation time stamp, reception time stamp, parsing time stamp) 8) streamedContents: - What are the elements on which this attribute is allowed. On the svg root only ? On the time container ? The RNG does not specify it. - The specification of 'discard' is completely unclear: In the sentence: "The contents of the document may be discarded as they are used. It is not a requirement that the contents are discarded." Why does it refer to 'the document' ? Shouldn't it be 'The contents of the element to which the attribute belongs, may be discarded as they are used. It is not a requirement that the contents are discarded.' Moreover, what does "as they are used" mean? 9) As we suggested in the comments on the Multiple Page, we believe the discard mechanism is underspecified. We propose to remove the streamedContents attribute, to rename it to 'discard' whose type would be the same as the 'begin' attribute. discard Value: = "never" | offset-value | syncbase-value | event-value | accessKey-value | wallclock-sync-value Initial: "never" Applies to: all elements Inherited: no Percentages: N/A Animatable: no Using this definition may mean that the document become in error in a way difficult to foresee, but it gives a lot more flexibility. An alternative would be to define an element with the following syntax <discard xlink:href="elementtobediscarded" begin="page1.end"/> 10) timelineBegin attribute: This notion is not linked to the streaming but also applies in progressive rendering cases, therefore it should be in the progressive rendering section. Chapter 8: Progressive Rendering -------------------------------- General Comments: 11) This chapter is quite unclear with respect to the Streaming Chapter. It should be clarified when a progressive rendering should be done, if the author has any possibility to indicate that he/she wants a progressive rendering. For instance, it seems important to write that streaming of SVG should imply Progressive Rendering. In particular, if the timelineBegin attribute is set to onStart, then progressive rendering should be turned on. 12) This chapter seems to imply that progressive rendering can only be done when a SAX parser is used. This is very very restrictive. An ad-hoc mechanism could update the tree without using SAX. 13) The following sentence: "The user agent updates the rendering following each startElement and/or endElement SAX event." implies an important overhead in the rendering phase. If the reading rate is high this would mean updating the rendering with a rate higher than usual (30fps ...). Best regards, Cyril Concolato, Jean-Claude Moissinac -- Ecole Nationale Supérieure des Télécommunications, Paris 46, rue Barrault 75013 Paris
Received on Friday, 5 November 2004 09:48:05 UTC