RE: Proposal for Extensions to HTML4

> >>> The concept of a null value is very important
> >> This is simply a matter of backwards compatibility with HTML4.
> >
> > Which is an example of why HTML4 is broken. Null values 
> just cannot be 
> > ignored.
> 
> An interesting point. Without sacrificing 
> backwards-compatibility, though, I don't know how to solve 
> this. Maybe an attribute on the form, requesting that all 
> controls (even unsuccessful ones) be submitted, with the 
> unsuccessful ones having the value ""?

A zero length string ("") is very different semantically than a null
value. A null value represents an unknown value while a zero length
string represents a known string value of 0 length.

> In XForms, how would a server deal with the case where a 
> field was not mentioned (due to a broken UA or malicious 
> user)? Would the processor handle that case as if the value 
> had been specified but left blank, or would the server have 
> anomalous behavior?

The XML Schema says exactly what should happen in this case. A field
with a minOccurs of 1 and nillable=false requires a value, and unless
other constraints, this value can be "". And of course, there are many
other settable constraints if you need them.

> I'm trying to work out what the practical impact of this is 
> on Web servers. As it is very poor design to let the 
> (inherently untrusted) input determine how the server 
> proceeds, I would think it would make sense for the server to 
> be directed by its own list of expected fields, and if those 
> fields are not in the input, then to treat them as the empty string.

Xforms allows is much more flexible in these regards because it is built
on top of XML Schema, which is widely implemented across all platforms.
If the input isn't valid, the server knows right off the bat and takes
appropriate action.

David Cleary

Received on Tuesday, 9 December 2003 09:13:06 UTC