Does this snippet bother anybody else? "For best results, we recommend that the SOAP examples be run in a modern ACL image. In ANSI CL images, most of the SOAP symbols must be mentioned with vertical-bar escapes since case is significant."

Not that I use ACL or anything.

And why does it bother you?

I guess it depends on what they mean by "for best results". If it really means "Our code will not work unless..." then that would be a problem. |Otherwise,| I |can| |see| |how| |this| |would| |get| |annoying| |quickly.|

I suspect that is what they mean. That seems to be the trend at Franz. If you don't use "modern" mode, I believe their Java integration code just won't work...

To answer the anonymous question, case-sensitivity is a step backwards, IMO. Yes, Java uses it successfully as a consistent convention (class vs. method vs. constant), but in Lisp, I think it's a case of fixing what wasn't broken. The only advantage is (possibly) easier integration with case-sensitive languages like Java. On the down-side, you risk breaking existing code and interoperability with other Lisps, and introducing the same annoying-to-catch errors that exist in other languages. Do you really want (eq T t) to be false?

wrt what's important, a gentleman started working on a soap layer for cl-xml about 18 months ago (judging from looking at the write dates on the files). as i gather from his last messages, he ended up having other more important things to do. maybe franz now has customers who actually need it.

I work at Franz... and I find this all so interesting...

When interfacing with other languages that are case sensitive, what do you (case sensitive haters) believe we should do (other than force the use of |this| |like| |this|)?

Java is case sensitive, so jLinker is case sensitive. SOAP is case sensitive, so our SOAP API is case sensitive. SOAP and jLinker work better in modern mode, but you can use them in ANSI mode by using |'s. Case closed, pun intended.

Comments like "if you don't use "modern" mode, I believe their Java integration code just won't work..." are FUD and nothing more. It seems to be fashionable to throw around FUD when talking about modern mode, too.

one of the issues behind this, is whether the data which represent names (that is, "universal name" constituents of some object which has been, or will be, encoded as xml) are the same kind of thing as the symbols used to represent a program.

it would appear the franz's jlinker, soap, &co implementations either follow from a decision that this should be so, or at least give the programmer tools which work best if that is so.

several years ago, it became apparent that some of the things which one needs to to with xml documents are not readily done with symbols and that some of the advantage which symbols have over other data objects when used to structure programs - namely that the language offers you constructs to bind things to them, would likely be undercut in the xml-processing realm, whether by the practice of evolving the standards in that domain without a systematic approach to (re)naming, or by a concern about resource-related risks, or security risks order *read-eval*

in any case, as a consequnce of c.l.l discussions it became apparent, that names didn't need to be symbols. even franz's examples which purport to demonstrate how effective it is to be able to code case-preserving symbols, could have been implemented differently - without regard to code case conventions, if the underlying name implementation were done appropriately.

...

Yes, I agree 100%.

This sounds like another meeting of the Flat Earth Society.

Let's face it, the world beyond Lisp is case sensitive. C, C++, C#, Java, Perl, Python, xml ..etc..

Lisp must be able to communicate with that world to survive. Naming objects in that world with Lisp symbols is a good thing as Lisp symbols are powerful objects.

Maybe it's time for a new law based on Greenspun's Tenth Law of Programming, such as:

Any sufficiently large Common Lisp program that interfaces with objects outside of Lisp contains an informally-specified, bug-ridden, slow implementation of a case-sensitive symbol table.

James said "as a consequnce of c.l.l discussions it became apparent, that names didn't need to be symbols".

I say: I'd like to see some references (ie, article ids).

wrt "the c.l.l thread" one can get there from here:

http://groups.google.com/groups?hl=en&lr=&ie=ISO-8859-1&q=xml+names&btnG=Google+Search&meta=group%3Dcomp.lang.lisp.*

my conclusion was, one should be able to choose.

wrt "informally-specified, bug-ridden, slow implementation[s] of [] case-sensitive symbol table[s]"

a well specified, standard, robust, flexible, bullet-proofed, fast, portable one would be a nice thing.

any references?

or bug reports?
...

Hmmm, my understanding was that Amazon mostly uses REST. I guess they have a SOAP and/or XML-RPC thing too, but they've got a whole lot of REST-lovers up there.

"Annoyingly complex" is an understatement. I'm pretty sure that the whole _point_ of SOAP is to be non-human-readable or -writeable.

Re: "For best results...".
This was an unfortunate choice of words that has been analyzed way beyond any reasonable expectations.

What was intended was the suggestion that a Modern ACL would save the programmer some typing and maybe help avoid some errors.

Names in XML and in SOAP are case sensitive - that is simply a fact of life we must deal with.

If a Lisp application chooses to interact with SOAP, it must mention names correctly, in a case sensitive way. We chose to denote SOAP names with Lisp symbols because we wanted to take advantage of the uniqueness feature implemented by Lisp symbol interning.

The ACL SOAP implementation works correctly and effectively in ANSI CL. In Modern ACL, the programmer can use fewer keystrokes to say the same thing.

watch the delimiters on that url [ http://www.cl-xml.org/documentation/names.html ]