Re: High-Quality Dynamic SVG Viewer

Jim,

Extra-extra big apologies for not responding to this
in an appropriate time frame. We *really* do appreciate
your input (especially as the most prolific Last Call
and CR feedback submitter!).

Here's my summary of your message:
- there is a lot of confusion around when an animation
  could begin
- solution, remove High-Quality Dynamic SVG Viewer from
  conformance

My response is:
- we've already agreed to look at animation, in particular
  multiple timelines, when an animation shoudl start and
  the firing of SVGLoad, in SVG 1.2. With any luck we'll
  be able to resolve the inconsistencies soon.

- probably the most important error is the "animations
  will start running" in the progressive rendering part.
  Obviously this is not clearly specified.

- 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. At least having
  the criteria means that viewers can plan to have support
  for the criteria, even if they might not be able to 
  conform without future clarifications in the spec.

The other thing to consider is that we were very reluctant
to make these kinds of changes in the SVG 1.1 timeframe
as it is a legacy from SVG 1.0, not new work.

I'm sure this doesn't completely appease you, but I tried :)

Dean


On Tue, 26 Nov 2002, Jim Ley wrote:

> 
> Hi,
> 
> I've mentioned, various parts of this problem in previous messages,
> and there's been a fair bit of discussion, however none has realy
> resolved my concerns. And so I'm going to explain in more detail my
> issues with the Conformance requirements for a "High-Quality Dynamic
> SVG Viewer", the problem exists in both the SVG 1.0 recommendation,
> and the proposed rec. 1.1.  My apologies for not raising it sooner in
> the process but my interpretation of certain parts were so at odds with
> what's since been discussed in the mailing lists, that I simply didn't
> consider it to be wrong.
> 
> The main problem is:
> 
> http://www.w3.org/TR/SVG/conform.html#ConformingHighQualitySVGViewers
> (and the equivalent 1.1 section)
> 
> | A Conforming High-Quality Dynamic SVG Viewer must support
> | the following additional features:
> |
> | Progressive rendering and animation effects (i.e., the start of the
> | document will start appearing and animations will start running in
> | parallel with downloading the rest of the document).
> 
> Exactly what the above means, is completely unclear, and incompatible
> with other parts of the specification.
> 
> One problem is the SVGLoad event which is described as:
> 
> | The event is triggered at the point at which the user agent has
> | fully parsed the element and its descendants and is ready to
> | act appropriately upon that element, such as being ready to
> | render the element to the target device
> ( http://www.w3.org/TR/SVG/interact.html )
> 
> The problem here is that in the dynamic viewer, the SVGLoad event must
> fire after rendering, this was clarified when I raised this
> previously, and a workable - although out of line with the spec -
> interpretation was given. I now believe the spec should be tightened
> here to remove the inconsistency.
> 
> The next problem is with animation, in
> http://www.w3.org/TR/SVG/animate.html we're told "For SVG, the term
> presentation time indicates the position in the timeline relative to
> the [exact time at which the 'svg' element's onload event is
> triggered] of a given document fragment.  Despite the clear use of
> Document Fragment here, The interpretation put on this in www-svg
> messages is that it is only the root svg element that this applies to,
> and there is only one timeline - this is a seperate issue really, but
> since it is irrelevant other than to a high quality dynamic viewer,
> it's really part of the same.  It also seems odd that the timelines 0
> time is before any rendering has been done, this means unless the
> rendering is instantaneous a user will not see the initial position,
> and position the user first sees is dependant on how long the
> rendering takes.
> 
> The interpretation from the mailing list means that there can be no
> timed based animation before the root SVGLoad fires, which has me
> wondering exactly what "animations will start running in parallel with
> downloading" means.  If we take other event based animation, I don't
> believe this can start either, since from
> http://www.w3.org/TR/2001/REC-smil-animation-20010904/#Unifying says
> "From a scheduling perspective, the time is described as unresolved
> before the activation. Once the element begin or end has been
> activated, the time is resolved." so they still have to happen at a
> time, but the timeline hasn't started so no time exists. This is from
> the SMIL rec though, and I certainly have little experience of it, so
> my interpretation may be wrong.  I cannot currently see how it is
> possible to have animations before the SVGLoad event if there's only
> one timeline, yet a High Quality Dynamic Viewer requires it.
> 
> A third problem is with what a viewer does with an invalid document,
> consider a missing </svg> from the root element, in this case the
> error is on the root element, however
> http://www.w3.org/TR/SVG/implnote.html#ErrorProcessing says "The
> document shall be rendered up to, but not including, the first element
> which has an error" in which case no content should be rendered.  This
> is another incompatibilit.
> 
> I do not believe that a High-Quality Dynamic SVG Viewer is compatible
> with what is specified in the rest of SVG, there are no implementations
> that I know of, ASV 3.0 is close, but the SVGLoad events at least do not
> fire at the appropriate places.  I believe the simple way of resolving
> this issue especially as since as we have no implementation we cannot
> hurt anyone, is to remove the High Quality Dynamic SVG Viewer from the
> specification. This important requirement can then be revisited in SVG
> 1.2 where implementaton experience and tight specification can be
> provided.
> 
> Again, apologies for the lateness of the issue.
> 
> Regards,
> 
> Jim.

Received on Wednesday, 15 January 2003 17:42:38 UTC