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: > 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 syntax". > 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 <cowan@xxxxxxxx> 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