Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

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, Elliotte Rusty Harold, THE Java XML man (HYPERLINK , HYPERLINK 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]>: