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

Re: Individual comments on SRFI 107

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.



On 11/18/2012 11:36 AM, John Cowan wrote:
Here are the individual comments on SRFI 107 that have occurred to me
so far:

Thanks for the feedback!

1) Attribute names and values cannot be replaced by enclosed expressions.
That should be allowed.

They can, unless I'm missing your point:  The attribute name is
given by an xml-name-form, which can be an xml-enclosed-expression.
Likewise, xml-attribute-value can contain xml-escaped.

What is not supported explicitly are attribute-valued expressions.
One could extend xml-true-attribute to:

xml-true-attribute ::=
    xml-name-form=xml-attribute-value
  | xml-enclosed-expression

where xml-escaped would be an expression that evaluates to an
attribute value.

2) It should be made clear early that the lexical syntax does not allow
whole XML documents to be inserted.  I'll send another email suggesting
a way to represent whole documents.

Ok.

3) It should also be made clear early that the lexical syntax is a
superset of XML syntax.

I can change the abstract to:
  We specify a reader extension that reads data in a superset of
  XML/HTML format, and produces XML-node values.

If we drop the semantics parts as you recommended earlier, then perhaps:

  We specify a reader extension that reads data in a superset of
  XML/HTML format, and produces conventional S-expressions.


4) I believe that the namespace mapping passed to $xml-element$ should be
wrapped in (quote ...) in order to lift the restriction that $xml-element$
needs to be a macro rather than a procedure.

I don't believe that works - at least it might cause major problems.
The namespace mappings provide bindings that should be visible in
enclosed expressions. So at least in the my use-case $xml-element$ has to be a macro. Though one could still wrap the namespace list in quotes to support some use-cases that don't need that, and then applications that want to support
true lexical namespace bindings can just strip the quotes in the macro.

5) Change $resolve-qname$ and $entity-reference$ to $xml-resolve-qname$
and $xml-entity-reference$ for uniformity.  I realize that in Kawa QNames
have a wider scope than just XML, but that won't necessarily be true
in other implementations of SRFI 107.  If these forms seem too verbose,
$xml-qname$ and $xml-entity$ work for me.

In XML terminology, an "entity" is a "piece of text" - for example a file
or a string.  An entity reference is an identifier that resolves to an
entity.  So I'm not sure ($xml-entity$ NAME) would be a good idea.  I don't
mind a slightly more verbose $xml-entity-reference$.
--
	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/