Re: Feedback on Working Draft of 07 Dec

Chris,

Thank you for your great review.
The XForms WG will consider your input for the next XForms Working Draft
version.

----- Original Message -----
From: "Chris Haynes" <chris@harvington.org.uk>
To: <www-forms@w3.org>
Sent: Tuesday, December 11, 2001 11:51 PM
Subject: Feedback on Working Draft of 07 Dec


> Dear XForms team,
>
> I've just read most of XForms 1.0 (WD 07 Dec 2001, ) as  'light'
> evening reading. This is my first real entry into this topic.
>
> My initial comments and reactions may be of help. Even if I'm wrong,
> they may indicate where other newbies might also have difficulties or
> concerns.
>
> 2.1 Internationalisation
> I find the claim that "Using XML 1.0 *ensures* ... internationalised."
> a bit strong.
> All XML seems to provide are:
> -  Internationalised characters sets,
> -  The ability to add 'xml:lang' attribute tags.
> The implementer of XForms has *lots* to do herself in this area
> (see 8.1 - Input - for example)
>
>
> 2.1 Multiple device support
> Surely you mean
>     "..re-present the user interaction on different devices."
> not
>    "...re-purpose the user interaction to different devices."
> The purpose is the same, the presentation is different.
>
>
> 2.1 Declarative event handlers
> I found the grammar clumsy here, you seem to be contrasting an
> adverbial phrase ( "statically analyzable") to a noun phrase
> ("imperative program code").
>
>
> 2.4 Providing instance data
> I found the same identifier "as" occurring as an element name, an
> attribute name and an attribute value confusing (but perhaps
> unavoidable?).
>
> The example made me wonder if
>
> <payment as="credit"  cc="" exp="" xmlns="..." />
>
> would also be acceptable,
> or alternatively if there was some permitted syntax such as
>
> <payment  xmlns="..." >
>      <as default="credit" />
>     <cc/>
>     <exp/>
> </payment>
>
>
> 3 Terminology - computed expression
> 'relevant' and 'calculate' should be presented in a different font
> (e.g. italic).,
> or else the example put in brackets.
>
>
> 6.4.2 Binding constraints last para
> Spurious 'an' (or should be 'and' with comma removed?)
>
> 7.4.2.1 avg()
> Picky mathematicians might say this should be called 'mean()'.
>
>
> 7.4.3.2 now()
> Surely the comment "(normalized to UTC)" belongs in the first
> sentence - referring to the time, not in the second, referring to the
> zone.
>
>
> 8.2 textarea
> Control of word wrapping
> As far as I can tell, the combination of XForms 1.0 and CSS2 does not
> support the functionality of the HTML textarea 'wrap' attribute. The
> CSS 'overflow' does not really cover this. Although control of the
> wrapping is a 'presentational' issue belonging in a style sheet, maybe
> the XForms team has to lobby strongly to ensure this is supported in
> CSS3.
>
>
> 8.3  secret
> A 'well known' browser has the useful behaviour that, if a page is
> returned to using the browser's 'Back' function, the password field is
> cleared. Would this be useful behaviour to mandate for the 'secret'?
> Or maybe just say that is can *only* take input from the user(see also
> 9.2 below)
>
> 8.6 range
> "xsd:gDay" should not be in bold.
>
> 8.12.1 Common Attributes
> The example states that the class attribute can have a space-separated
> list of classes.
> The comments below imply that only a single class may be used.
> Which is it?
>
> 9.2 refresh
> ...and other means of returning to a page, using Back or calling up
> bookmarked pages.
> As the developer of an application which uses long sequences of forms,
> I find the
> ability of the user to go back and re-present 'old' data at any time a
> nightmare.
> What I currently have to do is allocate a serial number to each page I
> generate, and 'slap the user on the wrist' if she uses the back
> button.
> Can I put in a plea for some better, specified, behaviour with this
> respect?
> Would it be possible to mandate that forms with non-inline data should
> always re-load that data each time the page is presented?
> Leaving it to the user's manipulation of her cache control is not good
> enough.
>
> 9.15 message
> IMHO messages *must* be given an identifier, so that it is possible to
> replace the content of the same modeless message panel, rather than
> create a new one. I believe this to be a *vital* usability feature - I
> could provide use cases if that would help.
>
> Review ended at section 10.
>
> There *is* someone out here reading this material :-)
>
> Hope this was of use,
>
> Chris Haynes
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Received on Wednesday, 12 December 2001 08:34:58 UTC