W3C home > Mailing lists > Public > www-forms@w3.org > September 2008

Re: XForms, the xf:header and the HTTP Accept header.

From: Aaron Reed <aaronr@us.ibm.com>
Date: Tue, 02 Sep 2008 12:11:13 -0500
To: www-forms@w3.org
Message-ID: <g9js83$sk5$1@ger.gmane.org>

I've been trying to reply all week but it keeps asking me to 'ok' the 
archival of my message even after I said 'ok'.  Here's trying again.

  > I'm leaning towards combine="prepend|append|replace|error" and then we
  > need to decide what the default is.

What would 'error' do?  I think that the default should be 'append', 
though not a strong opinion.

  > Keith's test cases show only one name, but multiple values.  I don't
  > see a reason to disallow multiple value elements, since it's already
  > allowed anyway. So (3) third axis would be value element document
  > order in the XForms document.

Multiple value element children aren't allowed under a header element
according to the schema.  I don't really care if you eventually allow it
as long as the schema is corrected.  It shouldn't affect the
implementation much.  Since we are allowing multiple header elements
anyhow, I don't see it is that much more work for the developer if the
spec continues with enforcing name/value pairs.  Either way is fine with me.

  > The value element has a value attribute, which is converted by XPath
  > string, so that means if it's a nodeset it's a space-separated list of
  > values.  That seems to me to be wrong.  So we need to make it either
  > be single-valued or say that we have a (4) axis of multiple values of
  > the value element?
  > If everyone else thinks we should disallow multiple value elements and
  > treat nodesets in value as strings, we can, but it puts the author in
  > the business of doing concat and quoting.  It may be that we need
  > value/@nodeset, though there is no binding implied.

I'd vote that we keep the behavior of @value the same across all
elements in the spec and thus it should evaluate the xpath expression as
if it is a string.  I don't mind @nodeset, though that does imply
binding.  Maybe a new attribute like @valueset?

  > 2. Browser vendors may have headers that they wish to control
  > themselves, ones not defined in the HTTP protocol.  For example, Opera
  > Mini reportedly uses X-OperaMini-Features, and I can imagine that not
  > being settable.  Whether this is an error or a field to be silently
  > ignored, I don't know; what's your opinion and that of other
  > implementors?

Ideally I'd say that it should be reported to the form author, though
not necessarily as an exception, perhaps an xforms-????-error and if the
implementation allows for it, an error output in a console.  I can't
picture an implementation header that a form author would expect to be
able to change and want to halt submission if setting that header failed.

Received on Tuesday, 2 September 2008 17:38:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:21 UTC