[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplifying SRFI 109, part 1: entities
On 03/30/2013 10:57 PM, John Cowan wrote:
Per Bothner scripsit:
It is more important to preserve the XML conceptual "information
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
Yes, I actually consulted that today and noticed the "coincidence"
of the name. Glad to confirm my assumption they're one and the same.
(I also know a John Cowan socially, but he doesn't appear to be you ...)
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"
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
First, this SRFI also has a reader syntax for PI nodes, comment nodes,
and CDATA nodes.
There is no support for (top-level) attribute nodes, though you can
write them with a $xml-attribute$ constructor.
My assumption is a Scheme API for XML would have standard
function calls for creating DOM Nodes, and the SRFI-107
syntax would be basically syntactic sugar.
Some other languages also provide similar XML "literals".
My goal is not to embed XML documents inside a program,
but to provide a more familiar syntax equivalent to node
constructor expressions. XQuery has equivalent functionality
as this proposal: XML-style syntax for elements, PI, and
comments. For attributes and documents you need to use
"computed constructors". "EcmaScript for XML" is similar.
Visual Basic does support "XML Document literals", and
I guess we can add support for them. Perhaps we can allow:
#<!DOCTYPE root optional-stuff><root>...</root>
And of course we can use SRFI1-108 in some way.
However, doing this "right" adds a fair bit of extra
work and complexity. It also pushes the limits of my
expertise. The obvious reader translation is to an
$xml-document$ constructor. Beyond that things are less
obvious. Because the infoset for an XML document is rather
complex, it seems cleaner to use keywords - but alas keywords
are far from standard: We get into the question of
whether to use SRFI-88-style keywords or plain symbols.
I like SRFI-88-style keywords of course (Kawa has them),
but obviously this limits portability. (Though if we
add them to R7RS-large I'd have less reluctance ...)
If you think the name "XML reader syntax" is misleading,
we could change the name to "Basic XML reader syntax" by
analogy with SRFI-28.
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.
Updated in: http://per.bothner.com/tmp/srfi-109/srfi-109.html