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

[REBOL] Re: Interesting Article on repurposing software

From: bry:itnisk at: 29-Oct-2003 11:34

> bic> why do you think that Rebol could be really good at this (really > bic> good implying to me better than at other things, and better than > bic> other tools)? > > 1) It's designed to enable communication (the semantic exchange of > information). > > 2) It has a friendly native format that is easy to load and generate.
I like the friendly native format, but the world seems not to care about friendly native formats, they care about non-native formats, friendly or not. Besides which the friendly native format seems to stringently connected to the requirements of being a programming language, which is of course what it is, to be useful in Document like structures. I tend not to write a document in the same way I write a Rebol script. Rebol structure does not seem to me to be extensible in the same way that xml can be, thus it is not possible to add in stuff in a rebol script that application x does not understand but that application y does, one might say that one can do so as long as the rules of Rebol are matched, just as the rules of xml must be matched to do so with an xml document, but the rules of Rebol are tighter than xml.
> 3) We can build formatting dialects for various targets; think VID.
How easy is it to build consuming dialects for various targets?
> 4) PARSE > > 5) It's easy to generate data in various formats. >
it's harder to consume xml than it is in most other languages that I'm aware of.
> 6) EasyVID, make-doc, PDF-maker, ML, eText, etc. > I have to admit that I only looked at the examples for FOA, because > the downloads are so huge, so I can't say what the Java looks like > that makes it all happen; it can't be too small though. :) And the > XML/XSL stuff just didn't do anything for me as far as being clear and > understandable. >
the main benefit of xslt is its model and its wrapping of xpath, as long as one implements the model and xpath in a dialect then xslt would not be needed (other than of course that xslt is hopefully cross-language). The main detriment of xslt is its syntax. In erlang there's an xslt like implementation, that has most of the model but not the bad syntax. Some people find that the bad syntax is however a benefit as it is xml, which allows xslts to work on xslts. Note that I find xslt completely useless unless one has the concept of node-sets as supplied in nearly every processor by an extension function.
> I'd certainly like to hear opinions from others who have experience in > this area, particularly with other languages, or know of other systems > to compare against.
Well I feel confident enough to declare myself an expert in these particular technologies, I've also downloaded various versions of FOA and I really disliked it. I'm not a big java guy so I can't really comment on the code but all it basically was, was an editor for xsl-fo documents, as the best xsl-fo processors only generate pdf it basically was a buggy, slow, and hard to work with pdf editor. But it was free. I hate xsl-fo. But lots of experts in typographical systems etc. seem to find it a reasonable solution, my hatred is nothing to do with its theoretical underpinnings but really with its markup structure. I won't go into all those here, but I could really rant. The fo part of the name stands for formatting objects, and is supposed to provide a markup syntax for specifying all sorts of formatting, there are also formatting objects in the spec for aural formatting, but no one has implemented those yet* (basically I think the standard is gonna fail in a few years, without major retooling, in case no one's picking up on this here). The idea is of course that an xsl-fo processor could be written for different representations. FOP from Apache produces output of various quality in pdf, postscript, MIF, and text (think there's also an extension to produce TIFF); most of the major xsl-fo processors support svg embedded inside of the xsl-fo. There are some various xsl-fo processors for outputting RTF (I think FOP may output RTF as well, can't remember). Adobe's new Document Management Server works with xsl-fo. What are the benefits, businessmen see that it supports xsl-fo, happy day, w3c standard. Businessmen see it supports the rebol pdf-Maker dialect? Question: "Can my xml solutions work with that?" or something equally inane, that's an uphill sell, you see. I should probably stop with this now, cause I'm at work and I should probably actually work while here. We have a product that solves a lot of the problems with cross-media channels, and as much as I would love to be using Rebol all through it, there are very few points where I could see that Rebol would improve over what we have. And most of those points are in parts not core to the product, such as GUIs, or various components of the product for ftp, email, http integration. *I think the Daisy Talking Book standard might be making some use of formatting objects, but haven't looked at that in a while.