[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Simplifying SRFI 109, part 1: entities

This page is part of the web mail archives of SRFI 109 from before July 7th, 2015. The new archives for SRFI 109 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