RE: http-request/etc. and URI encoded references

What if in the future (XProc 2.0+), the specification decides to do
something with multiple (white space separated) URIs? Encoding them will
eliminate all possibility of that.

Also, what about cases where the URI is dynamically passed to the pipeline?
Forcing encoding means the pipeline author will have to decode the URI and
use the decoded version, just so it could be encoded again by the pipeline
processor. Needless to say that's a needless performance penalty.

Besides... that would make URIs unpredictable and the language harder to
learn. As an author, I'd expect I'll be able to just "copy&paste" an URI
wherever it is accepted. Forcing encoding means I'll either have to make a
habit of decoding URIs (either manually, or by always placing an extra
step), or avoid using any "%" encoded URIs altogether.

Instead, I suggest that it simply becomes an error if the value of any of
those URI accepting attributes is an invalid xs:anyURI.

-----Original Message-----
From: public-xml-processing-model-comments-request@w3.org
[mailto:public-xml-processing-model-comments-request@w3.org] On Behalf Of
Alex Milowski
Sent: Thursday, November 08, 2007 4:06 PM
To: public-xml-processing-model-comments@w3.org
Subject: http-request/etc. and URI encoded references


I think we need to specify that URI reference values used however all
steps should
be URI encoded.

For example, the 'href' attribute on c:http-request or the 'href' option on
load
should be URI encoded so that a reference to "my doc.xml" is encoded as
"my%20doc.xml"

 I'll have to dig up all the places where we need to specify this.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Thursday, 8 November 2007 22:15:18 UTC