Re: .html? File Extensions Perhaps Not So Harmful

I spent Friday and Saturday at a meeting dealing with TeleRehabilitation.

This combines data-networking-based extension of business processes with
medical strictness about how one assesses appropriateness for intended use.

In that context, I perceive a "dissemination plan" policy issue in this
thread.

The policy issue is rather broader than 'how' one assesses quality.  

But I would like to drop in the following tidbits from that world.

They disinguish between "effectiveness" as observed under laboratory
conditions
and "efficacity" which has to be based on use under field conditions; in the
home or in the hospital or in the doctor's office, depending on the
service-delivery context intended.

And they talk about suitability for the intended use in terms of "ecological
validity."

In telerehabilitation, when the technology-push advocates want to claim
success
based on mere effectiveness, there are the clinicians already established in
place to push back and demand controlled studies of efficacity before putting
something new into the standard canon of practice.

While I was, at the meeting, telling the clinical community that some of their
'received' standards of evidence are too confining for the TeleRehabilitation
domain of applications, it is equally true that technologists, and W3C are
dominated by this group, underestimate the requirements for qualifying
technology as appropriate for its intended use and could benefit by taking a
few process pages from the medical book on this point.

* on the thread-initial question:

If the protocol doesn't return a .svg from the server when the server has both
and the client requests a .gif with an 'accept' heading that prefers .svg,
then
the protocol is broken.  The server should know when it has eqivalents for the
.gif URI and what they are.  That's a basic accessibility requirement. 
[WCAG2]  That suggests an architecture trouble report leading up to a
re-engineering process for HTTP, perhaps.  Or at least current-problems input
to CC/PP.

[40X:  Be strict in what you emit and lax in what you accept.]

It is not a quality process for _us_ in QA to try to resolve the policy
issue; 
we can help by mining the medical practice lore to nominate evaluation methods
to determine what the deployment status of 'Vary' should be at this time.  But
to develop a quality product, W3C needs to be rippling these issues to include
the communities who would have to implement any fix.

Al

At 12:01 PM 2001-10-15 , Alex Rousskov wrote:
>On Sun, 14 Oct 2001, Mark Nottingham wrote:
>
>> I don't think this merits 'screw up'. Proxy caching is an
>> optimisation mechanism; most don't support Vary in that they don't
>> cache anything that is content-negotiated. They will still service
>> the request, and indeed handle the Vary header correctly.
>
>Yes, in theory. In practice, when a bandwidth-starving network admin
>notices that some bandwidth is wasted because of the Vary headers,
>they will make sure that Vary header is ignored or otherwise violated
>because it screws up their preferences on how bandwidth is used. As I
>am sure you know, people do much worse things to save a few bytes of
>HTTP transfers...
>
>When your uplink is 56Kbps, and you have hundreds of users, a caching
>proxy is not just an optimization mechanism. People will violate
>protocols if protocols affect their bottom line and can be violated.
> 
>> If a proxy doesn't support Vary in the sense that it will go ahead
>> and cache the entity without considering Vary in the cache key, it's
>> broken. That's their fault, not the content provider's.
>
>I did not assign faults. A "we will use this cool feature despite it's
>actual support or effect" attitude is protocol-legal, but not the kind
>of behavior I would recommend.
>
>And, if you want to assign faults based on HTTP/1.1 requirements, keep
>in mind that most proxies out there either speak HTTP/1.0 or are not
>HTTP/1.1 compliant.
>
>Alex.
>
>> On Thu, Oct 11, 2001 at 09:30:23PM -0600, Alex Rousskov wrote:
>> > On Thu, 11 Oct 2001, Ian B. Jacobs wrote:
>> > 
>> > > Now that SVG is a Recommendation, we'll probably start publishing
>> > > several versions of an image, so that you get the best format your
>> > > browser supports.
>> > 
>> > .. and probably screw up most caching proxies out there because they
>> > still cannot handle Vary headers [correctly].
>> > 
>> > Alex.
>> > 
>> 
>> -- 
>> Mark Nottingham
>> <http://www.mnot.net/>http://www.mnot.net/
>>  
>> 
>

Received on Monday, 15 October 2001 13:32:16 UTC