Re: Standards development (was HTML forms)

Dan,

Thanks for your questions:

> Why are you so intent on getting this put into W3C specs, 
> and into implementation on user agents?

My goal has never been to get published in any particular 
organizations' specs; only to get the major browsers to  
implement microphone upload suitable for language instruction,
on all feasible platforms.  While I was working within the 
W3C, I didn't realize how much Microsoft and Intel were 
benefiting from the non-interoperable OBJECT/EMBED tags 
(normative or informative, platform dependence is antithetical
to the stated mission of the W3C.)  And even if I had brought 
it up then, I have no reason to believe it would have done any
good; I was in enough trouble as it was with those who seem 
to believe that the ability to specify pre-selected defaults 
is good user interface design.  The only public W3C argument 
for that position amounts to -- and this is a direct quote -- 
"any proposal that suggests markup that includes the word 
'device', ... should ring alarm bells."  My opinion on that 
matter is that any user interface rubric that generalizes 
markup form and style over function and substance should ring 
louder alarms.

An affirmative stance taken by the W3C would be preferable 
for many reasons, but the IETF's 'text/html' registration 
could do in a pinch.  I'm not willing to make that formal 
proposal without asking the W3C some more questions and 
giving them more time to consider the aspects of the device 
upload specification that they have never addressed in 
public at all, and in most cases have not addressed even 
within their members-only HTML Working Group discussion areas:  

First, the Content-device header, which would enable a server 
to tell whether a picture, for example, came from a scanner or 
a camera, or whether a sound file came from disk or a microphone.  

Second, the Content-type-alternates header, which would allow 
for some rudimentary content negotiation, for example sending a 
jpeg when the gif format was unsupported or vice versa.  

Third, the MAXTIME attribute, which would allow compressed 
media with nonzero durations (e.g., sound and video but not 
images or text) to be limited by a maximum number of seconds 
instead of the less useful maximum number of bytes.

Forth, the various security considerations in the draft:
  http://www.bovik.org/device-upload.html#Security

Fifth, there is the matter mentioned above, regarding the 
selection of a default input DEVICE, upon which the HTML Working
Group chair and I have agreed to disagree.  This is a vital 
issue because of the legacy implementations that browsers have 
chosen for the ACCEPT attribute, using it as a filename pattern 
instead of a list of MIME types.  The presence of the DEVICE 
attribute would allow them to make a clean break from that 
legacy interpretation of ACCEPT, removing one of the claimed 
barriers to implementation.

There are other minor issues too, but the first two above are 
very important because they were brought about by the specific 
requests of the IETF Application Area during the IANA 
Content-type header registration process.  The W3C has 
repeatedly refused to accept revisions to the original flawed 
NOTE -- http://www.w3.org/TR/device-upload -- in accord with 
those recommendations from the IETF, even after revisions were 
submitted by another of the W3C's own members.  If the W3C 
continues to refuse revisions to multipart/form-data header
parameters explicitly rejected by the IETF, why shouldn't the 
IETF make a corresponding amendment to the text/html MIME 
type registration?

> What's wrong with using other applications that can do 
> exactly the same thing?

That's the heart of the matter:  What will people actually use
for educational applications?

The best implementations of the best specification aren't worth 
the electrons they're written on unless they actually benefit 
educational applications such as spoken language instruction, 
along with asynchronous audio conferencing, transcription from 
dictation, and the high-quality transmission of device input 
under low-bandwidth conditions.  That last problem would benefit 
more of the decision-making Internet community than any 
educational application -- imagine! high-quality async voice 
messaging on your portable wireless box!!! -- but is not 
the source of my passion for the last remaining anytime/anyplace 
learning hurdle:  spoken language instruction.

Cheers,
James

Received on Friday, 31 March 2000 19:54:13 UTC