RE: online conversion support from xsd to rng?

["Drew Adams" <drew.adams@oracle.com>]

>>> I think there are two areas of primary concern:
>>> (a) conversion between XML and Lisp trees (nested lists)
>>> (b) routines for manipulating the tree
> >
> > Once you've converted XML to Lisp you lose all XML-level 
> > access, transformation, etc.  IOW, once in Lispland, no
> > XPath, XQuery, XSLT,...  If your processing of
> > XML also involves, well, XML processing (e.g. XQuery 
> > transformations) that is part of the given, then you've lost that.
> >
> > IOW, conversion to conses and processing using Lisp can be 
> > useful, but depending on your context there can be a cost.
> 
> This is nonsense. XPath and friends are not bound to the external
> representation of the data in any way. They operate on the 
> DOM tree.

Precisely - XPath and friends operate on a DOM or streaming SAX events or PSVI
or XQDM or...  They don't operate on conses. Unless those conses map to a DOM,
PSVI, etc.

No one said anything about using an external representation of the data - except
you.

> So as long as your XML conversion to sexp format is lossless (which it
> should be, of course),

Well sure, if you build a Lisp DOM or the equivalent, so that nothing is lost.
That's not the impression I got from the (admittedly meager) description given.

I think we are partly saying the same thing - we are both saying, I guess, that
unless you have a full, lossless representation you are losing out on something.
You are supposing such a representation; I wasn't hearing that.

And even a perfectly faithful representation is not much without faithful
access. By that I mean access faithful to the existing (standard) XML processing
languages - IOW support for them. I suppose (hope) that's what you mean by
saying that you "need an XPath etc. implementation for your language".

> you lose nothing, only gain the advantages of
> saner format (i.e. sexp) both for humans and the machine -- you just
> need an XPath etc. implementation for your language.

Sure. "Etc."  Y'a qu'a...

A Lisp DOM API, for example ("(b) routines for manipulating the tree").
Or a Lisp PSVI. Or an XQuery Data Model. Or all of the above. Etc.

A fairly far cry from "ad-hoc car/cdr climbing for (b)" (depending on what was
meant).

Don't get me wrong. I'm certainly not against the idea. Just pointing out that
Lisp is not XML (for better or for worse), and for XML processing you need a
representation of XML (nodes - I'm not talking text anymore than you are).

And to be really helpful you need interfaces with (support for) XML languages
(e.g. XQuery). That is, *IF* you want to take advantage of existing code in such
languages and support those languages with a Lisp API (yes, Virginia, there is
lots of existing XML processing code).

If not - if you just build your own Lispy access etc. (e.g. car/cdr climbing)
without support for XML languages, then yes, you forego existing code and
applications written in them.

I'm not familiar with `xml2sexp' - maybe that's truly all that's needed. But
this description didn't really inspire confidence:

"The idea is to flee the angry brackets into the loving parens immediately.  (I
briefly looked at the pattern matching / transform primitives of XSLT and was
horrified.)"

That doesn't give me the impression that "you just need an XPath etc.
implementation for your language." It gives me the impression that the idea is
to not use (support) XPath, XQuery, XSLT, DOM, or any of the rest. Hence my
comment that dropping all of that represents a loss. Or, as I said:

> > IOW, conversion to conses and processing using Lisp can be useful,
 
^^^^^^^^^^^^^^^
> > but depending on your context there can be a cost.

It can be useful, but it is not the same thing as supporting XQuery code, XSLT
code, etc.