- From: Vasil Rangelov <boen.robot@gmail.com>
- Date: Fri, 9 Nov 2007 00:14:58 +0200
- To: <public-xml-processing-model-comments@w3.org>
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