From: james anderson
Subject: ANN: CL-XML 0.908: includes LW/ALLEGRO support
Date: 
Message-ID: <3B311B6C.AB42F0B8@setf.de>
greetings,

i have today posted a new version which include better http support and
compatibility with lispworks and allegro.

the xquery syntax remains, for the moment, that from the previous draft version.

the url remains:
  http://homepage.mac.com/james_anderson/XML/index.html

...

ps. anyone who happened to be looking today may have stumbled over
broken download links. please try again.

From: Mark Watson
Subject: Re: CL-XML 0.908: includes LW/ALLEGRO support
Date: 
Message-ID: <Co9Y6.23055$aV1.2300927@newsread1.prod.itd.earthlink.net>
Hello James,

I run LispWorks Pro under W2000.  I have been unable to get
either the XML or ATN packages to load.

Are any other libraries required?  For example, if I load
defsystem.lisp in the xml directory, I get:

Error: The file #P"XML:ATN;DEFSYSTEM.LISP.NEWEST" does not exist.

What is the deal with the .NEWEST extention?

BTW, I am most interested in just the XML parser.

Thanks,
Mark

--Mark Watson
--Java consulting, Open Source and Content: www.markwatson.com
From: Sam Steingold
Subject: Re: CL-XML 0.908: includes LW/ALLEGRO support
Date: 
Message-ID: <ug0ctrjsq.fsf@xchange.com>
> * In message <·······················@newsread1.prod.itd.earthlink.net>
> * On the subject of "Re: CL-XML 0.908: includes LW/ALLEGRO support"
> * Sent on Wed, 20 Jun 2001 22:24:34 GMT
> * Honorable "Mark Watson" <·····@NOSPAM_markwatson.com> writes:
>
> BTW, I am most interested in just the XML parser.

CLOCC/CLLIB/xml.lisp parses XML too.
<http://www.podval.org/~sds/data/port.html>

-- 
Sam Steingold (http://www.podval.org/~sds)
I haven't lost my mind -- it's backed up on tape somewhere.
From: Mark Watson
Subject: Re: CL-XML 0.908: includes LW/ALLEGRO support
Date: 
Message-ID: <FJtY6.1350$CF3.143650@newsread2.prod.itd.earthlink.net>
Sam Steingold wrote:

> CLOCC/CLLIB/xml.lisp parses XML too.
> <http://www.podval.org/~sds/data/port.html>

Thanks Stan,

I have had very good luck with your CLOCC/CLLIB/XML stuff, except that
it does not support XML namespaces (right?).  This is for a SOAP
application that requires namespaces.

-Mark

-- Mark Watson (remove _NOSPAM from my email address)
-- www.markwatson.com - Open Source and Java Consulting
From: Sam Steingold
Subject: Re: CL-XML 0.908: includes LW/ALLEGRO support
Date: 
Message-ID: <ubsnho1ax.fsf@xchange.com>
> * In message <·····················@newsread2.prod.itd.earthlink.net>
> * On the subject of "Re: CL-XML 0.908: includes LW/ALLEGRO support"
> * Sent on Thu, 21 Jun 2001 21:32:21 GMT
> * Honorable Mark Watson <············@markwatson.com> writes:
>
> Sam Steingold wrote:
> 
> > CLOCC/CLLIB/xml.lisp parses XML too.
> > <http://www.podval.org/~sds/data/port.html>
> 
> I have had very good luck with your CLOCC/CLLIB/XML stuff, except that
> it does not support XML namespaces (right?).  This is for a SOAP
> application that requires namespaces.

It does support namespaces, since 2000-06-14.
There have been many bug fixes since then too.

-- 
Sam Steingold (http://www.podval.org/~sds)
Lisp: Serious empowerment.
From: james anderson
Subject: xml.lisp / CL-XML
Date: 
Message-ID: <3B3317C6.4CE5D34C@setf.de>
hello.

i am curious about approaches to xml namespaces, so i took a look at
xml.lisp. i am at a disadvantage, in that it appears to depend on a
library which had no support for my working environment, MCL. i took a
pass at implementing what appeared to be the minimal dependancies to get
it to parse. i tried it on a few simple things. i observed:

if one requires namespace support, the process takes two passes. the
first, a raw parse, retains string values for names. a second pass is
available to process namespaces. this 2-pass process is a standard among
xml processors, most of which take the view, that they are parsing
things which exist in a strictly lexical domain. the second pass
produces name instances which are collected, as one would expect, in
namespace instance. where a namespace declaration was present, the names
are modelled with structures. in other instances interned symbols wre
used. in other the names remained strings. the distinguishing principal
was not obvious.

declarations appeared to be collected into instances which
were structurally analogous to the declaration forms, but not directly
indicative of a further use.

default namespace-attribute declarations did not appear to have been
recognized. that is, even a declaration which follows lexical
restrictions such as those set out in the "XML Namespaces FAQ"
(http://www.rpbourret.com/xml/NamespacesFAQ.htm - look at section 7) did
not appear to effect a binding within the document entity.

while it did intern names in declarations, the results were unexpected.
it did not use namespace-attribute declarations to infer the expected
names instances, but rather interned the individual components of
qualified names as symbols. this would leave additional work for the application.

i could not find any indication that it performed validation. the state
of the declaration instances did not lead me to believe that this was included.

xml.lisp appears to be quite compact (with a code mass a bit over 100k).
there may be some advantages there.


cl-xml parses, by default, to interned symbols. its document model
includes universal names, as opposed to the lexically apparent qualified
names and it endeavours to produce a closed complete model in a single
pass. to this end, it handles namespace declarations present in the dtd,
performing a manner of constraint propagation on the prefix bindings in
order to resolve universal names. this can be disabled - to leave either
the lexical names as strings, or to intern to a uniform package,
although i must admit i have not tested that option heavily as i'm not
convinced it should be used. should one, as another option, need to work
with parameterized/modualrized dtds, i've tried it out against xhtml
dtds, so those beasts should be ok too. it performs validation. with
namespaces, if present.

these features may be of advantage. it depends on what you need to do.

should anyone eventually use cl-xml with soap, i would be interested to hear
about it. in particular requirements which arise when
integrating/interoperating with http servers. if people are having
problems getting it to load in various environments, please do let me know.

Sam Steingold wrote:
> 
> > * In message <·····················@newsread2.prod.itd.earthlink.net>
> > * On the subject of "Re: CL-XML 0.908: includes LW/ALLEGRO support"
> > * Sent on Thu, 21 Jun 2001 21:32:21 GMT
> > * Honorable Mark Watson <············@markwatson.com> writes:
> >
> > Sam Steingold wrote:
> >
> > > CLOCC/CLLIB/xml.lisp parses XML too.
> > > <http://www.podval.org/~sds/data/port.html>
> >
> > I have had very good luck with your CLOCC/CLLIB/XML stuff, except that
> > it does not support XML namespaces (right?).  This is for a SOAP
> > application that requires namespaces.
> 
> It does support namespaces, since 2000-06-14.
> There have been many bug fixes since then too.
From: Louis Theran
Subject: Re: xml.lisp / CL-XML
Date: 
Message-ID: <theran-45B35C.17072526062001@news.americas.nokia.com>
In article <·················@setf.de>, ··············@setf.de wrote:
 
> if one requires namespace support, the process takes two passes. the
> first, a raw parse, retains string values for names. a second pass is
> available to process namespaces. this 2-pass process is a standard among
> xml processors,

You might want to take a look at the XML parser at 
http://wilbur-rdf.sourceforge.net/.  It supports namespaces in one pass.

^L
From: Mark Watson
Subject: Re: CL-XML 0.908: includes LW/ALLEGRO support
Date: 
Message-ID: <w4IY6.794$Un6.127659@newsread1.prod.itd.earthlink.net>
Hello Sam,

re:  CLOCC XML parser:
> It does support namespaces, since 2000-06-14.
> There have been many bug fixes since then too.

Right!  I just tried parsing a humungously large SOAP
request (with name spaces, of course), and it worked great!

Thanks,
Mark

--Mark Watson
--Java consulting, Open Source and Content: www.markwatson.com