Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
p:www-form-urldecode: relax restriction on names of www-form-urlencoded parameters #22
For example, the step could not parse submissions from the following form, because the
<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
This leaves XProc developers without a convenient method to handle arbitrary forms or URIs with arbitrary query components.
The inverse step,
The specification for the
However, the parameter names submitted from an HTML form are the values of
It seems to me that a web-friendly language like XProc should provide this as a built-in primitive. It's always possible to write your own step to decode www-form-urlencoded data, but it's quite complex since you have to both URL-decode (easy) and UTF-8-decode (not so easy) the
Would this solution (of using a map) also mean that steps would have to be allowed to produce maps rather than only documents? Alternatively, I suppose, a new
Another alternative would be to drop the step and replace it with a new xpath extension function that returned a map.
I'm gravitating towards the idea that a "document" in V.next can be any XDM value, including maps. Or any arbitrary non-XML value. So a document becomes something like a wrapper around a MIME type and a bag of bits.
Making XML fairly transparent seems obvious and necessary. I'd like to make it possible for other kinds of data (JSON, specifically, but equally RDF or CSV) to be equally transparent between steps designed to process them.
While I fully approve of steps being able to pass any kind of XDM item, I'm actually starting to think that in this particular case an extension function would be the better solution anyway (rather than a step).
We already have a huge number of handy xpath functions to parse strings, and the lack of a standard function to enable this, and hence the necessity for the
An extension function
<p:when test="p:www-form-urldecode(substring-after($uri, '?'))('My Parameter')='foo'"> <ex:foo/> </p:when>
It seems to me that often www-form-urlencoded parameters would be used in a URI, and would therefore need to preceded with at least a base URI or at least with
<p:string-replace match="//html:a/@href" replace="concat($my-base-uri, '?', p:www-form-urlencode($parameters)" />
In fact I wonder if it's even worth having that extension function? We could get by with XPath 3.1 maps and the
<p:string-replace match="//html:a/@href" replace=" concat( $my-base-uri, '?', string-join( for $key in map:keys($parameters) return concat( encode-for-uri($key), '=', encode-for-uri($parameters($key)) ), '&' ) )" />
Is the syntactic sugar worth it? Maybe it is.