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

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