- From: Dean Jackson <dean@w3.org>
- Date: Mon, 20 Jan 2003 14:47:45 +1100
- To: Jim Ley <jim@jibbering.com>
- Cc: www-qa@w3.org, www-svg@w3.org
Hi Jim, I've removed process-issues from this reply, which only contains the technical details. The process details will be continued on process-issues. On Thu, 16 Jan 2003, Jim Ley wrote: > > "Dean Jackson" <dean@w3.org> > > Here's my summary of your message: > > - there is a lot of confusion around when an animation > > could begin > > I'm also concerned about how well-formedness and "streaming" ties together. I suggest the following to resolve the issue: - Issue an ERRATA that removes the difficult phrase "animations will start running" (and rewords the whole point) in Conforming High-Quality Dynamic SVG Viewer. From previous discussion it is obvious that this requirement is not possible in SVG 1.1/1.0. - Provide explicit wording on the relationship between well-formedness and streaming. At the moment, the spec says that you can only render a well-formed document, which means that you can't do progressive rendering (since any partially downloaded file is not well-formed). The answer is to create a temporary well-formed version of the partial download (close all open tags, etc) and then render. IF the viewer can determine that the document is truely in error (not well-formed or something else) then it immediately swaps into error mode. - Clarify the fact that a document with an error should be displayed up to the point of error (which sometimes conflicts with the "up to, but not including, the element in error" wording, which means that a missing "</svg>" would cause the progressive rendering to disappear). - SVG 1.2 will include a feature from SMIL2 that should allow animations to begin before the document is fully loaded. This will require some work on the part of the authoring tool/author, but it will facilitate streaming in general. All these will obviously require the input of the SVG WG, but I think the general message is clear. How does this sound to you (and others)? > > - we don't absolutely have to remove High-Quality Dynamic > > SVG Viewer as it boils down to a conformance criteria that > > no viewer can pass. Obviously this is a bad thing, but > > at least it isn't a showstopper. > > It's unfortunate though that the spec contains features which have never > been implemented, indeed you have to ask how SVG 1.0 made it out of CR in > such a state, let alone SVG 1.1. This is not a feature - it's a conformance requirement for a High-Quality Dynamic SVG Viewer. We never tested that each conformance category had been met, but we did test each feature. I note that many W3C specifications reach REC without having fully conformant applications in each conformance category. Of course, it would be best if it was possible to be conformant, so hopefully we can fix that problem ASAP. Dean
Received on Sunday, 19 January 2003 22:47:57 UTC