Re: [SVGMobile12] SVGT12-207: Unclear rules regarding mediaCharacterEncoding and mediaContentEncodings

Hello www-svg,

Ian Hickson <ian@hixie.ch> wrote:

>> > The mediaContentEncodings attribute does not appear to require any 
>> > behaviour on the part of a renderer, although it hints at possible uses.
>> 
>> We were not sure what you meant by that. If the size was measured with
>> one media content encoding and the content arrives with a different
>> media content encoding then clearly the prefetch hint is stale and
>> cannot be used.
> 
> There is no requirement that the prefetch hint be used at all.

That follows from the fact that it is called a hint. Its extra
information, which may optionally be used to give a better user
experience. There is no requirement to perform prefetching; and if it is
performed, these attributes are one information source that allows the
user agent to make good choices. There might be other sources of
information - for example the user agent might be throttled to reserve
more bandwidth for a different application, or conversely it might be i
a mode where it fetches everything that is linked and caches it in
preparation for a period of offline use.


>  In fact, as 
> I mentioned, the mediaContentEncodings attribute does not appear to 
> require any behaviour at all on the part of a renderer.

As mentioned in our earlier responses, these attributes allow detection
of stale prefetch data. If the remote resource has been modified since
the content with the prefetch was created - different size, different
encoding, etc) then the user agent should not consider the prefetch data
to be reliable.

> Please clarify the specification so that it is clear what rendering UAs 
> may or must not do with these attributes.

They may use the prefetch data to avoid startup delays and they may have
other sources of information besides this data and they should not
consider prefetch data which is found to be stale.

>  One way to do this would be to 
> include a clear subsection giving the processing model for this element, 
> giving the algorithm that must be used

That would seem to preclude other algorithms that might be better suited
to local situations. Two such scenarios (throttling, and cache filling)
were mentioned above. We certainly don't want to preclude that.

> to determine how much content to 
> prefetch, and then requiring (or allowing) the user agent to perform the 
> relevant network requests.

Allowing works; requiring does not.

>  Currently this section vaguely mentioned 
> possibilities but makes no testable normative requirements on rendering 
> user agents.

Testing this would require instrumenting the user agent, so that it
reported back how much data was fetched and whether the hints were
stale; also telling it to ignore any throttling or Quality of Service
load balancing that was being performed, be the only application
performing network requests, and so on.

It would then certainly be possible to have some test cases with known
correct prefetch data and others with known stale prefetch data;
to verify that the stale data was correctly detected, and to verify that
the correct amount of data had been prefetched.

Its doable, for implementors, but not suitable for end-user testing.

-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Thursday, 6 April 2006 12:54:01 UTC