Re: Addition of submission/@headers

Hi Mark,

This is a good suggestions and it would be great if it went into XForms. 
I do have some comments.

About the following wording:
1. Each element node is visited in document order. Each element that has 
one text node child is selected for inclusion....

I think the wording should be something like:
1. Each element node is visited in document order. Each element which 
does not contain mixed content is selected for inclusion...

The reason I ask for this change (or similar) is because people might 
want to comment the header settings in their form like:
<headers>
  <Destination>
    <!-- The destination header for the WebDAV protocol -->
    http://www.foo.bar/...

Since the XPath model will contain <Destination>#text<!-- comment> #text 
[http://www.foo.bar/...] the element will have two text children and it 
is no longer included. Another example is the case with mixed content. 
<a>#text<b>#text, should <a> be included in the headers? I believe it 
shouldn't.

The serialization of the text node makes it clear that it only 
serializes one single text node as the header's value. I think it should 
be the text content of the element (e.g all the descendant text children 
of the element). This is also the only way the <Destination> will get 
the http://www.foo.bar value as its first text node is empty.

Another thing is that the element <header/> might have an empty text 
node in the DOM (I do this in my implementation to have a node ready if 
someone binds using ref="header/text()"). But should this header then be 
present or should it be omitted?

Best regards,
David




Mark Birbeck wrote:
> Hi everyone,
>
> Continuing the idea of supporting other submission methods, there are a
> number of submission use cases that require extra header information to be
> present beyond that which is referred to in XForms, such as;
>
>   * WebDAV and SOAP--which build on HTTP--require
>     headers to indicate their presence;
>
>   * WebDAV requires headers to indicate some of the
>     parameters to its methods, such as COPY;
>
>   * HTTP requires headers for security-related
>     features;
>
>   * some 'web services' such as Basecamp require
>     additional headers.
>
> And so on.
>
> To allow XForms to interact with the increasing diversity of services on the
> web I'd suggest we add an attribute to submission that indicates where to
> get header information from. It would be an XPath expression, and would
> encode headers in much the same way that 'get' currently encodes name/value
> pairs for URLs. (I would think that the behaviour of the attribute would
> also honour relevance and validity.)
>
> The general architecture would then be that you end up with two sets of
> nodes, one to define the body and the other (optional) to define a header.
> Once these have been created (in section 11.1 step 1) then submission
> proceeds as normal, except that in step 3 (detailed in section 11.2) we need
> to also serialise the header information.
>
> --- STARTS ---
>
>   11.1 The xforms-submit Event
>
>     ...
>
>     1. One or two nodes from the instance data are selected,
>        based on attributes on the submission element (one for
>        the submission body, and an optional node for the
>        header). The indicated node or nodes, and all nodes for
>        which they are ancestors ... Etc.
>
>   11.2 Submission Options
>
>     ...
>
>     * headers (XPath expression)
>
>     ...
>
>     The headers attribute is used to indicate instance data
>     that will provide one or more headers to be serialized
>     for submission. Exactly how the headers are serialized
>     is protocol specific. There is no default value.
>
>     The steps for serialization of headers is as follows:
>
>       1. Each element node is visited in document order. Each
>          element that has one text node child is selected for
>          inclusion. Note that attribute information is not
>          preserved.
>
>       2. Element nodes selected for inclusion are encoded in
>          a manner specific to the specific protocol. (See
>          11.x below).
>
>          Note that contextual path information is not preserved,
>          nor are namespaces or namespace prefixes. As a result,
>          different elements might serialize to the same name.
>
>            * The encoding of EltName and value are as follows:
>              space characters are replaced by +, and then
>              non-ASCII and reserved characters (as defined by
>              [RFC 2396] as amended by subsequent documents in
>              the IETF track) are escaped by replacing the
>              character with one or more octets of the UTF-8
>              representation of the character, with each octet
>              in turn replaced by %HH, where HH represents the
>              uppercase hexadecimal notation for the octet value
>              and % is a literal character. Line breaks are
>              represented as "CR LF" pairs (i.e., %0D%0A). 
>
>       3. All such encodings are concatenated, maintaining document
>          order.
>
>   11.x Encoding serialised headers for HTTP
>
>     When serialising headers for use in an HTTP submission,
>     element nodes are encoded as EltName: value, where :
>     is a literal character, EltName represents the element
>     local name, and value represents the contents of the
>     text node. The separator character used between pairs
>     of encoded name/value pairs is a newline character (\n),
>     e.g. EltName1:value1\nEltName2:value2\nEltName3:value3.
>
>     If the same element appears Duplicate headers will be created 
>
>   Example:
>
>   The following shows how to encode a WebDAV request that
>   will COPY a collection, and is based on the example at [1]:
>
>   <instance id="inst-copy-headers">
>     <headers xmlns="">
>       <Destination>
>         http://www.foo.bar/othercontainer/
>       </Destination>
>       <Depth>infinity</Depth>
>     </headers>
>   </instance>
>
>   <instance id="inst-data">
>    <d:propertybehavior xmlns:d="DAV:">
>      <d:keepalive>*</d:keepalive>
>    </d:propertybehavior>
>   </instance>
>
>   <submission
>    action="http://www.foo.bar/container/"
>    method="copy"
>    headers="instance('inst-copy-headers')
>    ref="instance('inst-data')
>    replace="instance"
>   />
>
> This would result in the following request:
>
>   COPY /container/ HTTP/1.1
>   Host: www.foo.bar
>   Destination: http://www.foo.bar/othercontainer/
>   Depth: infinity
>   Content-Type: text/xml; charset="utf-8"
>   Content-Length: xxxx
>
>   <?xml version="1.0" encoding="utf-8" ?>
>   <d:propertybehavior xmlns:d="DAV:">
>     <d:keepalive>*</d:keepalive>
>   </d:propertybehavior>
>
> [1] http://www.webdav.org/specs/rfc2518.html#rfc.section.8.8.8
>
> --- ENDS ---
>
> Regards,
>
> Mark
>
>
> Mark Birbeck
> CEO
> x-port.net Ltd.
>
> e: Mark.Birbeck@x-port.net
> t: +44 (0) 20 7689 9232
> b: http://internet-apps.blogspot.com/
> w: http://www.formsPlayer.com/
>
> Download our XForms processor from
> http://www.formsPlayer.com/
>
>
>
>   


-- 
--------------------------------------------
David Landwehr (david.landwehr@solidapp.com)
Chief Executive Officer, SolidApp
Web: http://www.solidapp.com
Office: +45 48268212
Mobile: +45 24275518
--------------------------------------------

Received on Monday, 3 April 2006 09:33:54 UTC