Re: [xslt] output escaping (again!)

[Bruce Miller <bruce miller nist gov>]

Daniel Veillard wrote:
> On Sun, Mar 23, 2003 at 03:47:06PM -0500, Bruce Miller wrote:
>>The following two similar URI's are _different_ (and maybe invalid):
>>  (2)  data:text/plain%2CHello%2C%20World   (No <data> part)
>>  (3)  data:text/plain,Hello, World     (space & 2nd comma not allowed)
> 
>   Spaces are not allowed, not negociable. Maybe in IRI though 
> I do think it's a bad idea and I'm not the only one !

Well, of course that was the point: Only (1) was valid!

The space, base64, etc are all red herring issues 
(not that I'm accusing you of intentionally sidetracking me).

Here's a simpler example to get to the point:
  (4) data:text/plain,Hello
  (5) data:text/plain%2CHello

Case (4) is valid, but libxml won't let me create it.
Case (5) is INVALID -- rfc2397 _requires_ the "," and 
data component --- libxml creates invalid URLs!! :>

>>>  Your specific problem should be fixed in the next release. For the
>>>general case I don't think it's doable.
>>
>>I agree!! Since libxml can't read my mind, I'm responsible for telling
>>it what I want.  If libxml 
>>  (a) _only_ converted non-ASCII and
>>  (b) supported str:encode-uri, (or fn:escape-uri from XPath2.0) 
>>it would be simple (but verbose!):
> 
> 
>>  <a href="{concat('data:text/plain,', str:encode-uri(@data),true())}"> ...
>>Then <foo data="Hello, World"/> would give me case (1).
>>
>>Alas, str:encode-uri isn't implemented in libxml, nor anywhere else, according
>>to http://www.exslt.org/.
> 
> 
>  wrong it's available at the xsltproc level !

Indeed it _is_ there now! [I didn't reallize how old my libxslt had gotten!]
So, if libxml wouldn't go second guessing me, I should be able to create
any valid URL, right?
Given that the Right Solution is available, there's no reason for
libxml to mess with the uri's (other than the non-ascii rewrite), is there? 
:>

bruce