Re: Comments on "WICD Full/Mobile 1.0"

* Kevin E Kelly wrote:
>Please find the responses below marked with [KEK], 

Thanks. I'm afraid it's not clear to me at the moment what is beeing
proposed after the various changes announced on this list have been
applied. When should I expect publication of new Working Drafts for
the four last call documents? Per the W3C Process that would be in
about a week, so I'll only comment in brief and review your response
in the light of the new drafts once published. Also, I still have not
received a reply to

other than some sort of auto response telling me that the mail server
is unable to deliver the mail, as pointed out before on this list. I
would appreciate to hear from the Working Group regarding the matter

>  I've looked at and
> and I think the
>  * For accessibility, conforming user agents should profile the
>    option of switching off audio.
>[KEK]  This line has been added to both profiles
>          "For accessibility, conforming WICD 1.0 user agents should 
>profile the
>          option of switching off audio. [UAAG]."

It seems odd to add this as it was there before, you've just added "WICD
1.0" and the UAAG reference to the text I quoted above. In any case, my
concern was that this text should not be in the profile at all. The same
for the next change:

>  * For accessibility, conforming user agents must provide the
>    option of pausing, rewinding, or stopping video. 
>[KEK] This line has been added to both profiles
>          "For accessibility, conforming WICD 1.0 user agents must
>          provide the option of pausing, rewinding, or stopping
>          video."
>to the extend that they make sense should be moved to "WICD Core 1.0"
>and the requirements for JFIF, JPEG, PNG support should be spelled out
>by changing "WICD Core 1.0" such that any supported bitmap format must
>be supported from both XHTML and SVG content; support for the formats
>would then be required through requirements in SVG.
>[KEK]  Since we strive not to change existing markups but rather combine 
>them as they exist (XHTML and SVG on this case) , this comment would be 
>best redirected to the SVG and XHTML WGs rather.  No changes have been 
>made with repect to this comment.

I think you misunderstood my request; in any case, I don't see the
relevance of the XHTML and SVG specifications in this case, as I'm
requesting to move text from the profiles to the framework. In any
case, if the CDF Working Group becomes aware of issues in the SVG
and XHTML specifications, it should work with the relevant Working
Groups to address the issues, rather than trying to work around
them, or ask reviewers to do that.

>The requirements for content do not make much sense to me; frankly, what
>should it say? That you can use any audio format you like, but if you
>use script it must be ECMA-262 compliant? That would not make much
>[KEK] The profiles currently states:
>        "No audio format is mandated in this profile.
>          [assert-audio-formats: 
>            Any audio format supported by the device must also be 
>            to be used with the <audio> element in SVG and <object> 
>element in XHTML. 
>          ]"
>[KEK]  This allows any audio formats supported by the device through the 
>named tags in the combined markup. No changes have been made with repect 
>to this comment. 

My comment refers to the definition of e.g. "WICD Full 1.0 Document
Conformance" which has e.g. "A conforming script language must be a
ECMAScript." I do not understand what this sentence means. There are
a number of similar phrases in the document, most of which do not
make sense to me.

>There are some related problems here, for example, "WICD Full 1.0"
>notes "A conforming style language is CSS" and that implementations
>must support that, the specification then also says CSS 2.1 is re-
>quired, and "WICD Core 1.0" requires CSS Media Queries support; I do
>not really think it would make sense to define a CSS 2.1 + CSS3MQ
>CSS profile specifically for "WICD Full 1.0" conformance.
>[KEK] Can you elaborate on why this does not make sense to you with a 
>specific technical issue or problem this conformance requirement makes? No 
>changes have been made with repect to this comment. 

Again, I do not understand what information the text is trying to
convey. E.g. the "WICD Full" draft has

  WICD Full 1.0 Document Conformance: 
    5. A conforming style language is CSS.

I do not understand the implications of CSS beeing a conforming style
language in the context of "WICD Full 1.0 Document Conformance". The
whole purpose of the statements above appears to be to provide some-
thing that can be referenced in the implementation conformance section,

  A comformant user agent MUST support all
  previously described comformant content.

so this would seem to be an attempt to say that implementations must
support CSS. If that is meant here, it's conveyed very poorly, and is
in fact misleading, since implementations are not required to support
"CSS" (whatever that means), but to support CSS 2.1 and CSS3MQ.

That implementations are required to support CSS3MQ is not clear from
the profile specification; the requirement is only part of "WICD Core",
which spells this requirement out in some section but omits it from the
user agent conformance section. So all in all, this is very confused.

>"WICD Mobile 1.0" is confused about whether ECMA-262 or ECMA-327 must
>be supported. 
>[KEK]  The Mobile profile references ECMA-327 in its appendix, the Full 
>profile references ECMA-262. No changes have been made with repect to this 

The 'References' appendices do not meet the requirements of e.g. W3C's
manual of style or the QA specification guidelines, and don't follow
common W3C practise for such sections; in any case, I don't really see
a reference to ECMA-327 in either document, there is only a hint that
the compact profile might be referred to in a heading in the "Mobile"

>"WICD Mobile 1.0" 3.3.1 clarifies the semantics of the 'handheld' media
>type, I do not think this is "CDR"-specific in any way, this text should
>be moved to the specifications that define the semantics of this type.
>[KEK]  Some context for the target of this profile is included to clarify 
>the intent  and target of the profile.  No changes have been made with 
>repect to this comment. 

Please cite rationale for this decision.

>I don't think the resulting documents really merit separate technical
>reports, and I am not really convinced there is much value in having
>special terms for user agents that implement the specified set of
>[KEK] No changes have been made with repect to this comment. 

Please cite rationale for this decision.
Björn Höhrmann · ·
Weinh. Str. 22 · Telefon: +49(0)621/4309674 ·
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · 

Received on Friday, 10 March 2006 01:31:54 UTC