Email list hosting service & mailing list manager

Individual comments on SRFI 107 John Cowan (18 Nov 2012 19:36 UTC)
Re: Individual comments on SRFI 107 Per Bothner (18 Nov 2012 20:17 UTC)
Re: Individual comments on SRFI 107 John Cowan (18 Nov 2012 21:07 UTC)

Re: Individual comments on SRFI 107 Per Bothner 18 Nov 2012 20:17 UTC

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
xxxxxx@bothner.com   http://per.bothner.com/