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)
|
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/