[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.
