XML support in Rebol
[1/7] from: pwawood::mango::net::my at: 20-Dec-2004 11:52
In an interview at O'Reilly's OnJava (HYPERLINK
http://www.onjava.com/pub/a/onjava/2004/12/15/erh-interview.html
http://www
..onjava.com/pub/a/onjava/2004/12/15/erh-interview.html), Elliotte Rusty
Harold, THE Java XML man (HYPERLINK
http://www.cafeaulait.org
http://www.cafeaulait.org , HYPERLINK
http://www.cafeconleche.org
http://www.cafeconleche.org) makes a number of
good points about XML:
Perl lagged for several years in the XML space because it wasn't yet
Unicode-savy, and Larry Wall first had to Unicode-enable Perl before he (or
anyone else) could think seriously about supporting XMll.
One of the major impedance mismatches between Java and XML is that a Java
char is not in fact a Unicode character; rather it is a UTF-16 code point.
Lisp programmers wear different glasses; they insist on seeing XML as
simply S-expressions with angle brackets instead of parentheses, a model
that's only marginally closer to reality.
The only proper way to approach XML is by understanding and accepting its
unique structure without trying to force it to fit some other paradigm, be
that paradigm objects, S-expressions, records and fields, or something
else.
Of course, XML isn't a patch on Rebol values when it comes to swapping data
between different platform. It is however getting to be used more and more
often in system-to-system interconnectivity.
Is the XML support good enough for Rebol to be used as a "universal system
connector"?
Regards
Peter
[2/7] from: pwawood:mango:my at: 20-Dec-2004 12:16
It seems that I have uncovered another odd Mailing List problem, the
embedded HTML links in the text seem to have been duplicated !!!
Peter
[3/7] from: bry:itnisk at: 20-Dec-2004 11:45
I've actually thought quite a bit about this subject as my area of expertise is
xml, although I don't really use Rebol anymore I think the following would be a
good approach:
integrate support for some open source libraries for handling xml, my
suggestion
would be support for libxml and libxslt as well (given that for certain forms
of
xml xslt is the best tool).
Do not bake any further support for xml into the parse-xml.
Why not? Because parse-xml will currently accept non-valid, not well formed xml
and provide a simple parser for it. This is a strength as long as one also has
a
parser for providing validity checking and other commonly required
functionality.
instances of some of the more common xml dialects one encounters have the
distressing habit of not being well-formed, for example various versions of
RSS,
parse-xml provides a simple way to work with that.
[4/7] from: SunandaDH:aol at: 20-Dec-2004 7:06
Interesting comments, thanks Peter.
I seriously dislike XML for many of the things it is being used for -- too
many people taking it beyond its core competence and producing unpleasant
architectures based on hierarchical data structures.
But for what it is for -- basically a universal form of data exchange -- it's
a million times better than its predecessor, which was, essentially CSV files.
REBOL has native, natural, and elegant handling for CSV -- simply use parse.
But for XML, REBOL is still in the 20th Century.
Which is curious. Because REBOL is a messaging language. And XML is
increasingly the lingua franca for messages.
Sunanda.
[5/7] from: grantwparks:earthlink at: 20-Dec-2004 15:29
Hi All,
I am a Rebol newbie and I haven't worked with the XML libraries mentioned earlier, but
I have done a ton of DOM and XSLT work with XML and I was wondering if the standard series/block
function/refinements could be adapted for a parsed XML document tree. I don't right
off envision how the ancestor, etc. axes would be handled, but when drilling down or
selecting nodelists, would the series model seems to be a good start?
Grant
[6/7] from: pwawood:mango:my at: 21-Dec-2004 10:13
Hi Bryan
As far as I can tell by inspecting the source of parse-xml, it is a
mezzanine. The point being that it is written in standard Rebol. You can
preserve it's current functionality indefinitely by copying the source and
creating your own parse-xml-bryan. You would of course also have to copy the
underlying xml-language (dialect?) to xml-language-bryan as well. The only
issue from there on would be if RT changed the behaviour of a "native" (ie
written in C) word or a datatype.
So RT could bring parse-xml up-to-date and you could still retain the
current behaviour.
By the way, why don't you really use Rebol any more?
Regards
Peter
[7/7] from: bry:itnisk at: 21-Dec-2004 23:23
well i'm not discussing parse-xml from the point of view of what i want, so
there's is no reason for me to make a copy of it and so forth, other than if i
wanted to use it to do, as i discussed, parsing of xml instances that were not
well-formed.
i guess i don't really use rebol because i noticed that i never had
opportunities for using it in work situations without having to fight extra
hard
for that opportunity. i did have opportunities for using python, python with
the
right libraries was as productive in doing the simple stuff as rebol and more
productive for me in doing the complex stuff, mainly because not having much of
a chance to use rebol continually whenever i return to it for a bit of time
i've
forgotten most everything. i guess another reason i don't really use it anymore
is that it is hard for me to focus on some problem domain for which it is
amazingly more productive as far as i can see. i agree that it can be more
productive than some languages, but never with a special edge in something,
like
j offers an edge in calculation, or erlang offers an edge in handling
concurrency. add to this that much of what i do has to involve xml I need a
framework where i can handle all major xml technologies/subjects. major xml and
xml related technologies/subjects would be:
xml, namespaces, encoding, validation via doctypes, w3c xml schemas, relax-ng
schemas, schematron, soap, wsdl, xsl-t. there are other things i need in my
daily work that revolve around xml but these are pretty much all the things i
need to be able to deal with from within the programming language itself. some
of these things could be dropped, but considering how far behind rebol is on
all
the xml fronts i have a hard time justifying using it. that said i would
reiterate my belief that the best way for rebol to handle this need is to
provide hooks to some open source cross platform libraries, such as is provided
by the libxml projects. otherwise i believe implementing the xml stack would be
a killer for rebol.
--
Bryan Rasmussen
Quoting PeterWAWood <[pwawood--mango--net--my]>: