(Previous discussion continued)
Re: Simplifying SRFI 109, part 1: entities John Cowan 31 Mar 2013 05:57 UTC

Re: Simplifying SRFI 109, part 1: entities John Cowan 31 Mar 2013 05:57 UTC

Per Bothner scripsit:

> It is more important to preserve the XML conceptual "information
> model",

Absolutely, but SRFI 107 models only a part of the XML Infoset
<http://www.w3.org/TR/xml-infoset>, of which (ahem) I was the principal
editor.  In particular, it does not model anything above the element
information item.

> Also, some XML API preserve EntityRef as a unexpanded Node.  For
> example Scala:

It's true that the DOM provides such a node type, but I know of no
DOM-based parsers that actually generate nodes of that type.  In
addition, a reference to an undefined entity is a well-formedness error
except in the specific narrow circumstance where a document contains a
DTD with external components that the parser has not read (in which case
it is free to assume that the entity is defined in those components).

> I wouldn't want to preclude that kind of API.

Parsers are always free not to return nodes of that type, and to treat
all references to undefined entities as errors, and that's in fact what
they do.

> SRFI 107 as currently written does not support the concept of an
> XML document - whether we mean:  (1) XML document as a file format.
> (2) DOM Document as a data type for representing the "significant"
> information

It's the second concept I mean.

> SRFI-107 doesn't directly support either.  I think APIs supporting
> both are desirable - and SRFI-107 should hopefully work well with such
> APIs.  However, this process has dragged on long enough, and working
> with documents seems like new functionality that I think should be
> saved for future work.

In that case, perhaps this SRFI should be renamed "XML element reader

> Indeed, that is rather vague - and raises these questions:  (1) What are
> "standard Scheme character names"? I suggest going with the R7RS names.

I'm happy with that, of course.

> (2) When it comes to an implementation supporting "standard Scheme
> character names", is this a "must" or a "should"?  I could go either
> way.  (3) Do we want a different answer for SRFI-17 and SRFI-108/-109?
> I'd prefer not.

I'd prefer a SHOULD for all three SRFIs.

John Cowan <xxxxxx@ccil.org>             http://www.ccil.org/~cowan
"Make a case, man; you're full of naked assertions, just like Nietzsche."
"Oh, i suffer from that, too.  But you know, naked assertions or GTFO."
                        --heard on #scheme, sorta