updated SRFI-108 Per Bothner (04 Feb 2013 00:21 UTC)
Re: updated SRFI-108 John Cowan (04 Feb 2013 08:16 UTC)
Re: updated SRFI-108 Per Bothner (04 Feb 2013 20:29 UTC)
Re: updated SRFI-108 Per Bothner (04 Feb 2013 20:43 UTC)
Re: updated SRFI-108 John Cowan (05 Feb 2013 01:24 UTC)
Re: updated SRFI-108 Shiro Kawai (05 Feb 2013 02:11 UTC)
Re: updated SRFI-108 Per Bothner (05 Feb 2013 02:24 UTC)
Re: updated SRFI-108 John Cowan (05 Feb 2013 07:54 UTC)
Re: updated SRFI-108 Per Bothner (05 Feb 2013 08:15 UTC)
Re: updated SRFI-108 John Cowan (05 Feb 2013 15:42 UTC)
Re: updated SRFI-108 Per Bothner (22 Feb 2013 00:36 UTC)
Re: updated SRFI-108 John Cowan (22 Feb 2013 03:10 UTC)

Re: updated SRFI-108 Per Bothner 05 Feb 2013 08:15 UTC

n 02/04/2013 11:54 PM, John Cowan wrote:
> Per Bothner scripsit:
>
>> I've made a number of changes to SRFI-108.  Until the editors
>> have a chance to upload it, you can read it at:
>> http://per.bothner.com/tmp/srfi-108/srfi-108.html
>
> Two further suggestions:
>
> I like the idea of |$[$| and |$]$| as internal delimiters, but not
> their spellings.  Some Schemes may not have escapes; in R6RS mode it
> would be necessary to write these as $\x5B;$ and $\x5D;$ respectively,
> which are deeply unintuitive.  I suggest therefore that you adopt the
> entity names from <http://www.w3.org/TR/xml-entity-names> and go with
> $lsqb$ and $rsqb$ respectively.  That is only one character longer than
> the ||-escaped form, and is probably easier overall to type.

Yes, that is a good point.  I have considered $<$ and $>$ which have the
advantage of more readably indicating "bracketed-ness", but those
symbols should perhaps be saved for something else.  Maybe:
$<sqb$ and $>sqb$.

> Deferring the definition of "cname" to NCName is probably not a good
> idea; it also isn't clear whether the XML 1.0 1st through 4th Edition
> version is meant, or the XML 1.0 5th Edition and XML 1.1 version.
> Naturally I prefer the latter, but I would really prefer a self-contained
> definition: the cname must be a valid Scheme identifier (according to
> the implementation's definition) which consists solely of characters
> with Unicode general categories Lu, Ll, Lt, Lm, Lo, Mn, Mc, Me, Nd, Nl,
> or No (i.e. letters, combining marks, and numbers only).

That seems reasonable.  I think we might want to allow
hyphens and underscores; haven't checked their categories,

>> I've added support for indentation adjustment (&|),
>> comments (&#|comment|#), and continuation lines (&-).
>
> I presume this remark refers only to SRFI-109, which I have not yet
> re-reviewed.

They're supported (and implemented in Kawa) for both SRFI-108
and SRFI-109.   Not yet for SRFI-107, though I plan to add them
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/