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

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

From: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Tue, 2 Sep 2008 10:59:10 -0700
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF405A566B7@USA7061MS01.na.xerox.net>
To: "Aaron Reed" <aaronr@us.ibm.com>, <www-forms@w3.org>

Thank you Aaron.  If this list is too difficult we can move back to

1. Did you see Philip Fennel's proposal for 

        <xf:value value="default()/>

in the previous message on this topic?

My sense, as I said to Philip, is that this would be too hard to
implement, but I don't want to second guess you (at least not without

2. Other replies inline below.

>-----Original Message-----
>From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Aaron Reed
>Sent: Tuesday, September 02, 2008 10:11 AM
>To: www-forms@w3.org
>Subject: Re: XForms, the xf:header and the HTTP Accept header.
>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
>  > need to decide what the default is.
>What would 'error' do?  I think that the default should be 'append',
though not a strong opinion.

Error would act like bind does now: if there is more than one value
specified for a particular header, it would get an error.  Or maybe an
exception.  The theory being that you only want to set
"X-foo-obfuscator" property once, and if someone else tries to set it,
you want the form to be in error.

>  > Keith's test cases show only one name, but multiple values.  I
>  > see a reason to disallow multiple value elements, since it's
>  > 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.

It came from Keith Wells's test case.  It means you don't have to worry
about commas or whatever quoting mechanism is used in order to specify
multiple values for a header, as in this example:

    <xf:header combine="prepend">

>  > The value element has a value attribute, which is converted by
>  > string, so that means if it's a nodeset it's a space-separated list
>  > values.  That seems to me to be wrong.  So we need to make it
>  > be single-valued or say that we have a (4) axis of multiple values
>  > the value element?
>  >
>  > If everyone else thinks we should disallow multiple value elements
>  > treat nodesets in value as strings, we can, but it puts the author
>  > 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?

Perhaps we should just note this.  It's a shape we have a first-node
rule for ref and no corresponding way of doing it for value.
But perhaps it's a corner case, at least for now.
>  > 2. Browser vendors may have headers that they wish to control
>  > themselves, ones not defined in the HTTP protocol.  For example,
>  > Mini reportedly uses X-OperaMini-Features, and I can imagine that
>  > 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

It would likely be xforms-submit-error or xforms-serialiation-error, but
if you think it would be better to have the browser ignore requests
(silently or verbosely) then I'll report that.

Received on Tuesday, 2 September 2008 18:01:02 UTC

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