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