Re: Draft charters available; please comment.

* Thomas Roessler wrote:
>we have informed the Advisory Committee that we're working on
>draft charters for two Working Groups:
>
>  - Form Annotations for HTTP Authentication.
>    http://www.w3.org/2005/Security/htmlauth-charter
>    
>    Think of this as form-filler support on steroids, as
>    sketched in late May on this list.

I don't really understand what is being proposed. From your message in
May it seems you are looking for classes, ids, and perhaps some things
to put in <meta> or <link> so as to provide some functionality, but the
specific are very unclear to me. A problem statement would probably
help. I also don't understand how this relates to HTTP Authentication.
The draft mentions it, but the interactions are very unclear.

I note that in any case this proposal has considerable overlap with
<http://www.w3.org/Submission/web-forms2/>; I understand from
<http://www.w3.org/2006/Talks/0524-www-WAF.pdf> that Web Application
Formats is considering to work on this; I also think subjects relecant
to the proposed Working Group came up during the development of the
Member Submission. If W3C is going to work on "Web Forms 2.0", I'm
not sure why there should be a separate Working Group for "Form
Annotations".

As for "Xforms Working Group: This work is complementary to current
work in the Xforms Working Group that would give forms access to HTTP
headers, and HTTP Authentication mechanisms." It is not clear to me
which work this could be. I asked the XForms Working Group repeatedly
to include relevant functionality in XForms 1.0 and then XForms 1.1
and the Working Group was unable to provide a meaningful response;
the latest XForms 1.1 draft or its requirements Note do not really
discuss something that seems relevant.

>  - Web Security Context Baseline.
>    http://www.w3.org/2005/Security/wsc-charter
>    
>    Think of this as "Secure Metadata" and "Secure Chrome" put
>    together:  What should user agents display, and how can
>    they do this securely?

I don't understand "The group should focus on security context
information that can be made available through currently deployed
protocols." Is this meant to say things that require retrieval of
additional information is out of scope?

For the first deliverable the problem is not clear to me; it seems
there is supposedly information available to the user agent but it
does not make that information available to the user. Perhaps you
could list candidate information items that need to be available
to the user but currently are not? It's not obvious to me that more
information will help users to make better decisions.

The scope of the second deliverable is rather unclear. Which kind
of user agents are in scope? Mobile browsers? Web mail systems?
Mail user agents? Voice browsers? Screen readers? What would the
best practises cover? Concrete english phrases to use? Icons?
Dialog dimensions? Whether browser should allow window.status to
be written to? Whether to show the URLs of links somewhere? IDN
versus punycode?

I also note that it's important that web user agents integrate
with the platform they are running on and thereby applications
designed for the same platform. This might well preclude "inter-
operability" among browsers depending on the desired level of
"interoperability". In any case, if the second deliverable is
purely about UI design for native applications this should be
made very clear in the proposal since W3C does not have much
experience in this area.

Why are these two separate deliverables? Is there information that
must be available but for which the presentation is unimportant
and so would not be covered by the second deliverable? Is there
information that does not need to be avialable but for which the
presentation is important if available? As it stands the split
seems to risk that important context information about features in
the second deliverable is hidden in the first one, which I think
is not a good idea (cf. WCAG 2.0, where you have to go through
three very big documents to collect "what", "why", and "how").
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 20 June 2006 22:34:57 UTC