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

Thank you Aaron.  If this list is too difficult we can move back to
dev-tech-xforms.

1. Did you see Philip Fennel's proposal for 

    <xf:header>
        <xf:name>Accept</xf:name>
        <xf:value>application/sparql-results+xml;q=0.95</xf:value>
        <xf:value value="default()/>
        <xf:value>application/atom+xml;q=0.6</xf:value>
    </xf:header>

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
asking).

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
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.

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
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.

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">
        <xf:name>Accept</xf:name>
        <xf:value>application/sparql-results+xml;q=0.95</xf:value>
        <xf:value>application/atom+xml;q=0.6</xf:value>
    </xf:header>

>
>  > 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?

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,
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.

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.

Leigh.

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