Re: High-Quality Dynamic SVG Viewer

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" <>
> > 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.


Received on Sunday, 19 January 2003 22:47:57 UTC