Relax restrictions on names of www-form-urlencoded parameters

[Conal-Tuohy]

The p:www-form-urldecode step provides a way to decode submissions produced by HTML forms, but because only names that match the xs:NCName pattern are allowed, the step can't be used to decode certain form submissions which are themselves perfectly valid as HTTP POST payloads or as the query component of a URI.

For example, the step could not parse submissions from the following form, because the input's name contains a space:

<form action="/my-form-handling-xproc-pipeline" method="get">
   <div>
      <input type="text" name="example input"/>
      <button type="submit">submit example</button>
   </div>
</form>

Submitting this form would produce the request URI /my-form-handling-xproc-pipeline?example+input= which p:www-form-urldecode would be unable to parse.

This leaves XProc developers without a convenient method to handle arbitrary forms or URIs with arbitrary query components.

The inverse step, p:www-form-urlencode, is also unnecessarily restricted, but this in practical terms this restriction is less of a obstacle since it's easier to perform the encoding than the decoding.

The specification for the p:www-form-urldecode step says:

It is a dynamic error (err:XC0061) if the name of any encoded parameter name is not a valid xs:NCName. In other words, this step can only decode simple name/value pairs where the names do not contain colons or any characters that cannot be used in XML names.

However, the parameter names submitted from an HTML form are the values of name attributes of controls on that form, which are defined as CDATA; a much broader space than xs:NCName.

Although a c:param-set element which contains a c:parameter whose name is not a valid xs:NCName will not be usable as the input to a parameters port, this requirement is not a good reason to impose the xs:NCName restriction on the output of the p:www-form-urldecode step. If a pipeline author wants to use parameters produced by p:www-form-urldecode as the input to a parameter port, they can always filter the parameters first. Invalidly-named parameters should only cause an exception when they are used as input to a parameter-type port.

[Conal-Tuohy]

Moved to XProc 1.1 issue

[xml-project]

So: Can we close this?