Serializing XMLS documents that do not specify a namespace outputs NIL in the elements. The attached patch gives a reasonnable output.
Quoting Kim Minh Kaplan (kmkaplan@gmail.com):
Serializing XMLS documents that do not specify a namespace outputs NIL in the elements. The attached patch gives a reasonnable output.
Thank you, fixed in CVS.
(I am actually inclined to get rid of the "namespace support" in the XMLS builder completely, but fixing the no-prefix case is obviously necessary.)
What was the rest of the patch? Looks like support for a version of CLISP without gray streams support. I hope I can safely ignore that.
d.
On Tue, 2006-05-16 at 00:11 +0200, David Lichteblau wrote:
Quoting Kim Minh Kaplan (kmkaplan@gmail.com):
Serializing XMLS documents that do not specify a namespace outputs NIL in the elements. The attached patch gives a reasonnable output.
Thank you, fixed in CVS.
(I am actually inclined to get rid of the "namespace support" in the XMLS builder completely, but fixing the no-prefix case is obviously necessary.)
??? What do you mean by "get rid"? Do you intend to drop XML namespace support from cxml?
Cheers Ralf Mattes
What was the rest of the patch? Looks like support for a version of CLISP without gray streams support. I hope I can safely ignore that.
d.
Quoting R. Mattes (rm@seid-online.de):
(I am actually inclined to get rid of the "namespace support" in the XMLS builder completely, but fixing the no-prefix case is obviously necessary.)
??? What do you mean by "get rid"? Do you intend to drop XML namespace support from cxml?
Heh, no, of course not.
We are talking about the XMLS-compatible builder and serializer (xml/xmls-compat.lisp) which creates XMLS-style list structures like (parent (attributes...) children...).
XMLS allows the car to be a cons (name . namespace), but it is unclear what that namespace is supposed to be. XMLS implements it as (lname . prefix), but documentation says it's (qname . uri). The former is uninteresting, the latter might be cute if attributes supported the same, which they don't.
OTOH, this is just very trivial sample code anyway, which users can easily copy&paste and tweak to match their requirements, so nothing to worry much about either way.
d.
-
David Lichteblau -
Kim Minh Kaplan -
R. Mattes