Re: Editorial comments on Proposed XHTML Module: Web Forms 2.0

Ian, 

>> # 1.2. Relationship to XForms
>> Insert a new paragraph before the diagram along the lines of: "This
>> diagram shows how a Web Forms 2.0-capable browser could provide the
>> presentation layer for an XForms system:", if that's not too confusing a
>> way to describe it.
> "What diagram?" It's only a diagram in graphical UAs. Actually, the
> diagram is redundant with the following paragraphs, so it's alt text is
> "", which would thus cause confusion if it was captioned.

Point taken. However, I still think that the diagram needs a paragraph to 
introduce it. It's not until the paragraph *after* the diagram that you 
start to describe the transformation model, so when you hit the diagram, 
you've no idea what it's illustrating. If you move the diagram down by one 
paragraph, you'll get the 'overview' paragraph and then the diagram, which 
makes more sense (to me, anyway). 

Incidentally, is there any way you can make the diagram more compact? It 
really needs to be looked at while reading the text, but that's impossible 
given its current size. 

>> # 1.3 Conformance requirements
>> In RFC 2119, and many of the other documents that reference it, the key
>> words ('MUST', etc.) are capitalised, while in this document, they are
>> not. Append the sentence (from CSS 2.1): "However, for readability,
>> these words do not appear in all uppercase letters in this
>> specification."
> I'll be marking up the RFC2119 terms at some point, styling them with
> small caps in an alternate stylesheet or some such.

You, of all people, using presentation to imply semantics? I'm shocked! 
shocked! 

Sorry, couldn't resist. I guess that's ok, I'll just have to make sure I 
don't read the spec on my phone :) 

>> # datetime input type
>> As you're trying to illustrate that the UA is expected to show an
>> 'appropriate widget' (rather than force the user to use ISO8601),
>> perhaps you could change the example to one that does *not* use the
>> ISO8601 input format?
> Yeah, I'd like other widget examples. Again, noted, I'll see what I can do
> at some point.

I've made two alternate examples for the datetime type (attached, I hope). 
Let me know if they're ok, and I might see if I can make some more. 

>> # 5.4.[5.5] text/plain
>> Again, presumable the chosen encoding should be a superset of US-ASCII,
>> similar to 5.2.
> Actually no, there's nothing wrong with UTF-16 or EBCDIC in this case as
> far as I know.

How should the receiver decode the character set in these cases? If a BOM is 
used, I could see that that would work, though you don't mention that 
(should you?). Is this just a case that the receiver should have some idea 
what it's being sent? 

# This algorithm does not directly parallel the algorithm for
# application/x-www-form-urlencoded. This is mostly due to backwards
# compatibility concerns. 

Those concerns are with the x-www-form-urlencoded algorithm, not this one, 
right? 

>> # 5.5. [5.6] Semantics of method and enctype attributes
>> In the action tables, remove the 'Handle as if enctype was
>> application/x-www-form-urlencoded.' and span the above text down, as is
>> done for the 'delete' case, unless there is a difference.
> The difference is the semantics -- the "Handle as" cases are "errors", the
> others are the actual cases.

Oh, that's interesting: I hadn't realised that. 

Perhaps a note to that effect would be useful? 

# [5.6.7.] For javascript: actions
s/HTTP 204 Not Content/HTTP 204 No Content/ 

Regards,
Malcolm