This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: incompatible Kawa change: symbol vs. java.lang.String
- From: Per Bothner <per at bothner dot com>
- To: "Hoehle, Joerg-Cyril" <Joerg-Cyril dot Hoehle at t-systems dot com>
- Cc: kawa at sources dot redhat dot com
- Date: Tue, 03 Apr 2007 10:45:58 -0700
- Subject: Re: incompatible Kawa change: symbol vs. java.lang.String
- References: <F720C8A8AFC73D4B844C2D4CE13551D601F7DDD8@S4DE8PSAAFQ.mitte.t-com.de>
Hoehle, Joerg-Cyril wrote:
I've put the Java-String <-> Scheme Symbol mapping to great (IMHO) use
in a XML to Scheme SXML converter. The core issue is that as Scheme
symbols, all Java strings would be uniq'ified. EQ and MEMQ are useable
to match XML element names.
> If I understand the implications of this incompatible change in Kawa
> right, code depending on this property of Scheme symbols originating
> from <String> would break.
Yes.
The Kawa recommendation is to represent XML element names
using symbols, not strings.
If you use:
(define-xml-namespace PREFIX "URI")
then you can write:
'PREFIX:LOCAL-NAME
and
(PREFIX:LOCAL-NAME CONTENT ...)
evaluates to a gnu.kawa.xml.KElement object. For example:
(foo:a attr:"ATTR" "text" (foo:child))
You can even do:
(foo:,(string-append "aa" "b3") "text")
to get a KElement whose tag is foo:aab3.
Unfortunately
`foo:,(string-append "aa" "b3")
doesn't work, though it's probably a simple fix.
These are the same data types used for Kawa's XQuery
implementation.
Of course you can just use namespaces and symbols without using
the KNode/KElement classes.
--
--Per Bothner
per@bothner.com http://per.bothner.com/