This page is part of the web mail archives of SRFI 107 from before July 7th, 2015. The new archives for SRFI 107 contain all messages, not just those from before July 7th, 2015.
Per Bothner scripsit: > The reader *could* return a literal string in cases where there are no > enclosed expressions, but I feel uncomfortable with that - it seems > a bit hacky and inconsistent. For read/write round-tripping we have > the traditional string literals, so I think it is cleaner to have the > &{...} always return a ($string$ ...) form. +1, given that you want to include enclosed expressions. > Not hard-wiring in entity names is especially important for STFI-107, > since the XML/SGML model does allow user-defined entity names. But only if they are declared in a DTD, either externally or internally. SRFI 107 makes no provision for doing so, so I consider that argument to be unsound. If SRFI 107 is to allow arbitrary entity names, getting their values from corresponding Scheme variables is a sensible approach. However, in that case the SRFI 107 model must be extended to include at least a mechanism for declaring an external subset as part of a new "XML document" constructor. The SRFI 107 reader need not read this subset: it can be a programmer responsibility to keep it in sync with the definitions of entity names at the Scheme level. Alternatively, only the standard five entities should be allowed. I have added the SRFI 107 mailing list as a recipient. > Having these be hard-wired into the reader is not IMO in the spirit of > XML. Even if the reader uses a user-programmable table it would be > information-losing for the reader to expand the entity names. Having the five standard XML names wired into a SRFI 107 processor is definitely in the spirit of XML. > Even then using using a programmable read-time lookup table is clearly > less "Schemey" than using regular expand-time name-lookup. I agree that programmability at read time is a Bad Thing because of the phasing issues (the same as expand-time vs. read-time phasing). > I should probably also state that an implementation MUST support the > standard Scheme character names. You don't say which list of standard names you are referring to. R5RS mandates only "space" and "newline"; R6RS mandates "nul", "alarm", "backspace", "tab", "linefeed", "newline", "vtab", "page", "return", "esc", "space", and "delete"; R7RS-small mandates "null", "alarm", "backspace", "tab", "newline", "return", "escape", "space", and "delete". -- I could dance with you till the cows John Cowan come home. On second thought, I'd http://www.ccil.org/~cowan rather dance with the cows when you cowan@xxxxxxxx come home. --Rufus T. Firefly