Re: BRL reader problem.

[Per Bothner <per at bothner dot com>]

On 08/25/2009 11:22 AM, Dan Stanger wrote:
> Thank you for the patch.
> Other than the return type (FString) vs java.lang.String, would you
> expect the return values for old eval based BRLReaderString to be
> different than the current BRLReaderString ?

Well, there is the hack in that the current SVN version returns
an UnescapedData rather than a String.  That might not be what you
want.  An UnescapedData is like a string, but special characters
(such as '<') are written verbatim, even when the output is
sent to an XML/HTML formatter.

Note that UnescapedData does implement CharSequence, so it is
considered a Scheme string.

BRL Classic doesn't use an XMLPrinter, so XML escaping is done
by hand (or using utility functions), which can be more risky
(injection attacks) and possibly inconvenient.  Hence UnescapedData
isn't needed.  KRL mode does use an XMLPrinter, and instead
text in ]xxx[ becomes UnescapedData, while a regular string "xxx"
is a String (and so automatically gets XML escaping).

I think this is a useful convenition, but of course it isn't
fully compatible with BRL classic.

BTW I am thinking about adding support for XML syntax literals.
I'm leaning towards using the dispatch prefix #x< .... ># as in:

  #x<span id ="foo">Span with some <b>bold</b> text.</span>#

I'd add escaping:

  #x<p>The result is: [result]</p>#

Something similar would allow string interpolation and formatting:

  #"The result: [~5d result]"#

(This would also be the hook for string localization a la gettext.)

(All other things being equal, I would prefer curly braces rather than
square brackets for vanilla Kawa, but square brackets would make more
sense for BRL.)

(These features are on my wishlist; it's nowhere top of the list!)
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/