Interesting Article on repurposing software
[1/9] from: greggirwin::mindspring::com at: 27-Oct-2003 13:44
Hi All,
Seeing as how this is something REBOL could be really good at, and
something I'm interested in...
http://www.e4engineering.com/item.asp?id=50283
--Gregg
[2/9] from: bry:itnisk at: 28-Oct-2003 11:57
why do you think that Rebol could be really
good at this (really good implying to me
better than at other things, and better than
other tools)?
[3/9] from: greggirwin:mindspring at: 28-Oct-2003 10:51
Hi Bry,
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.
3) We can build formatting dialects for various targets; think VID.
4) PARSE
5) It's easy to generate data in various formats.
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.
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.
-- Gregg
[4/9] from: mfontana7:inwind:it at: 28-Oct-2003 21:26
> 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
<<quoted lines omitted: 14>>
> this area, particularly with other languages, or know of other systems
> to compare against.
I am not an expert in these things, but I have woked (or maybe played?)
with some tools designed to those things. Nowadays most web site are
proposed into at least 2 formats, one of the ,ainstream browsers (PC based )
and those for PDA under WAP connection.
It's about 3 or even 4 years that there are tools like TOMCAT able to
generate different layout from a single XML document by applying different
XSL, XSLT or whatever can describe a layout or schema to represent the
contents. And using PDF is no more difficult with PHP.
which again can be used as a translator from XML. And Java is quite a
powerful language that can make it all at once (beside speed).
I really see anything revolutionary in that article, but for the fact that
they maybe have an optimized easy to use tool, which TOMCAT and JSP is not.
So the only thing I can see here important is that document content is
really what matter and XML can easily make you parse through it without
messing around with the layout and appareance. The sort of thing it was
though for.
Now all you need is a powerful XML parser and some other tool to make it
become the kind of document you want, HTML, DOC, PDF or even PNG. This can
be achieved in many many ways.
As I see Rebol somewhat powerful for parsing, I can't see any poweful tool
for it for real translation. So, IMHO, I won't really define it as a good
solution, nor it would be my choice if I ever had to do etherogeneous
document creation.
These are just my opinion. I am not an expert in this area nor in Rebol at
all. Maybe someone else has a better opinion on this subject.
M&F
[5/9] from: greggirwin:mindspring at: 28-Oct-2003 15:55
Hi M&F,
M> So the only thing I can see here important is that document content is
M> really what matter and XML can easily make you parse through it without
M> messing around with the layout and appareance. The sort of thing it was
M> though for.
Right, the big bonus I see with REBOL is that your data format can be
much easier for people to work with--and no more difficult for
machines--than XML.
Behind the scenes, we can generate whatever we want, but from an
interaction perspective, what is the best solution or the most natural
way to work with this kind of information? That's where I'm
coming from. For example, how would a dialected REBOL solution compare
to a GUI built with Java that generates the XSL, and eventually
produces an XML file which is then repurposed?
-- Gregg
[6/9] 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.
[7/9] from: bry:itnisk at: 29-Oct-2003 12:02
M> So the only thing I can see here important is that document content
is
M> really what matter and XML can easily make you parse through it
without
M> messing around with the layout and appareance. The sort of thing it
was
M> though for.
>Right, the big bonus I see with REBOL is that your data format can be
>much easier for people to work with--and no more difficult for
>machines--than XML.
Again as I noted before REBOL's format does not seem to me to be a good
format for a document structure. The benefit of xml is it can be used
for flat data:
<people>
<person>Joe Applebaum</person>
<person>Fritz Frantzaum</person>
</people>
to document style data:
<body> here's some text
<p>hello <list><item>item 1</item><item>item 2</item></list></p>
</body>
to hierarchical data:
<people>
<person>
<name>
<first-name>Joe</first-name>
<last-name>Applebaum</last-name>
</name>
</person>
</people>
furthermore structures can be extended in various ways:
processing instructions:
<body> here's some text <?call-rebol now/year ?>
<p>hello <list><item>item 1</item><item>item 2</item></list></p>
</body>
which are passed on to the calling application.
Or namespaces:
<body xmlns:r="http://www.rebol.com"><r:word>now</r:word> here's some
text
<p>hello <list><item>item 1</item><item>item 2</item></list></p>
</body>
which dependent on an xml dialect processor can be processed thru,
ignored, or do something else.
>Behind the scenes, we can generate whatever we want, but from an
>interaction perspective, what is the best solution or the most natural
>way to work with this kind of information?
The problem is not generating data from a customer's input, the problem
is working with data that a customer has elsewhere. It could be a
database, it could be twenty thousand word files they've got lying
around.
> That's where I'm
>coming from. For example, how would a dialected REBOL solution compare
>to a GUI built with Java that generates the XSL, and eventually
>produces an XML file which is then repurposed?
I guess we're back to what FOA is doing, I don't necessarily think that
FOA's solution is a good one, considering that I think I've built a
better one.
Most visual xslt generators are crap as well, as is the case with most
tools that generate code visually imho.
[8/9] from: bry:itnisk at: 29-Oct-2003 12:55
>>Behind the scenes, we can generate whatever we want, but from an
>>interaction perspective, what is the best solution or the most natural
<<quoted lines omitted: 3>>
>database, it could be twenty thousand word files they've got lying
>around.
By the way, this all makes me think of something I was considering
adding into the website generation part of our product.
Websites have the possibility of having different modules, for example a
mime-type module which analyzes various xml formats and returns the
mime-type for the xml document, so that if you have a file with an rss
extension that is RDF 1.0 you get the proper mime-type back.
One module we have returns folder structure as xml, this then gets
consumed by the front-end display module.
I was thinking that I could make a rebol generation module, basically
cause it might be a cool way to build the structure for other stuff
later:
So for example if one went to
http://mysite.org/rebollers.php?page=filebrowser.php&mappath=rootfolder&
submappath=stuff
(the website generation app allows you to generate either php, asp, or
aspx based sites)
it would give you the folders files, etc at the location of
http://msyite.org/rootfolder/stuff
something like
Rebol[Title: "Generated FolderStructure
http://msyite.org/rootfolder/stuff"]
Rootpath: http://msyite.org/rootfolder/stuff
Folders: ["folder1" "mycoolfolder"]
Files: ["file.xml"]
Resources: ["file"] ; files can have resources found in a folder at the
same ;level with _files in the title, so if file.xml has a resource it
will be ;found in a folder at the same level called file_files.
Fmx: true ; if the folder has a file found in it called index.fmx it is
used by the filebrowser module to put in welcoming text for that folder,
and to point at resources specifically used by the folder.
Other types of xml documents, data sources, modules etc. when consumed
by the rebollers front would return variant rebol scripts. So that for
example a vcard xml format would return the information for a persons
vcard in rebol consumable format, calendar information the same, etc.
A very old, beta version of the products generated sites can be found at
www.mediamaxx.biz
Here's an example of the filebrowser module in display format:
http://www.mediamaxx.biz/oio/assembler.asp?TITLE=Schemaer&mappath=First_
project_web&page=Filebrowser.asp&submappath=xsd
anyway, if websites were common that did this - which of course they
aren't as yet ;) , would people here find it a good tool? If so, does
anyone have any particular wants for what kind of rebol should be
returned from the following formats:
1. rss newsfeed
2. excel xml workbook
3. a blog calendar, showing posts for various dates of the year.
4. an events calendar, showing upcoming events.
Also in discussing the mimetype module above, where it returns the
mime-type of a resource, one of the things it does with vcard for
example is return a vcard in the vcf structure employed by most
emailers. Currently I'm working on a maillist service which converts
emails to xml, & posts them to a site. If one gets an xml file that has
been converted from email, should one have the possibility of requesting
it output as email? Should it be output as email by default?
[9/9] from: maximo:meteorstudios at: 29-Oct-2003 9:10
> -----Original Message-----
> From: Gregg Irwin [mailto:[greggirwin--mindspring--com]]
<<quoted lines omitted: 12>>
> much easier for people to work with--and no more difficult for
> machines--than XML.
If I may give an example, when I received data from a univercity for seismic vibration,
I was able to do a load directly on the file !!!
it seems that for most humans the use of
word: value
makes a lot of sense and basically, I had a huge block with a fixed number of items which
maked up the header. I know I was lucky, but still, the fact that rebol is capable of
determining the datatype of file contents simply by its written form makes all file handling
pretty natural.
> Behind the scenes, we can generate whatever we want, but from an
> interaction perspective, what is the best solution or the most natural
> way to work with this kind of information? That's where I'm
> coming from. For example, how would a dialected REBOL solution compare
> to a GUI built with Java that generates the XSL, and eventually
> produces an XML file which is then repurposed?
The system does seem to innovate in that you do not seem to need a template layout file
to create the output but rather, a master converter which uses contexts to decide how
to layout the output. What I find is the problem, is that you then get a universaly
bland expression of all the data. basically, They decide how any given context will
generate output and then just feed data to it.
that actually looks alot like a dialect to me. Its a programed engine which reacts to
fed data. Although there only really seems to be the make-doc (and better variants)
specification in terms of rebol-centric file specification, you can still create different
output engines, its just someone still needs to program the output module, they are not
yet available.
There might be one which already exists which outputs to a view application, but I'm
not sure.
basically, with rebol, (being portable, small and complete) there is no need for a hundred
megabyte shamefully large monster to maintain. and also, because it has view, it can
easily do more than JUST create a static file, with the data. It could open a window
and start a MM presentation...
in rebol, creating a write once publish many engine is child's play. simply because
data is more than simple content. it includes structure and can even contain actual processing
which will only be done once the context is known. So instead of putting actual data,
you could just insert a litle block of code which will be executed on the client. This
is easy since it does not need MBs of shit to perform. just a few words can do a lot.
If I use remark.r as an example, I can reformat the data to a completely different site
within one evening. This includes changing the menuing layout, gfx, actual look, and
even some of the contents throughout the whole site sithout changing any of the src pages.
The whole thing is built in html-like syntax, but because you can add your own tags,
creating many of the more advanced layouts, like the news actualy is just one tag with
content. remark does all the rest, and it can react to context. If it where built within
a cgi framework, then it could effectively be even more flexible.
The content does not change, but its interpretation is volatile.
my 2 cents
-Max
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted