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

[REBOL] Re: - R3 GUI

From: greg:schofield:iinet:au at: 9-Sep-2007 9:14

Carl thanks for the pointers I have not read it before.Carl thanks for the references I had not read it before. And thanks for the references I had not read them before: <> Interestingly, I agree with just about all of it. Yet, I had waited a long time for XML, (that is long before HTML, and before I had heard of SGML). But it is typical of the computer industry to miss the point, the articles are spot-on in their criticism. In a sentence: XML is excellent for marking up Literature - but useless for simple information. Where structure is important, but is only mediated by human understanding, then XML comes into its own, making what is implicit but understood by the human mind, explicit and understandable to the computer. If the point is only to supply software with data and it is the software that makes it useful alone then XML is misplaced. If the data needs to be saved, and may be used for other things =96 then XML is a good format for that (it is put into a passive state). Converting REBOL scripts (ie data scripts especially) to XML is, unlike any other language I know, a trivial thing. Unambiguously converting it back, is likewise trivial (there is a delay naturally). If I am using a REBOL rolladeck to keep my contacts, I don't want to reproduce it in parts when I need sections of its elsewhere, ideally I want it in one place in a form that suits its use (ie in passive saved form, translated into whatever I need at the time). Finally I do not necessarily want to go through a line editor, or my rolladeck software to correct things when perhaps I have made a systematic mistake, the easiest path may well be to use the mark-up as a general editing tool in a decent XML Word Processor (which alas does not yet exist). Even if my data is kept in a DataBase, if I need to edit chunks of it in unexpected ways, I need it to be translated into a form made for editing by human beings. This is awkward, because the essential element is missing. A decent XML Word Processor. In short, where meaning is implied by complex human interpreted structure then explicit XML is a very good means to do so, especially that in general it should be passive (have things done to it) rather than as an active agent. Another simple rule is generally XML is good when the content far outweighs the tag lengths, but not always, sometimes it is the complexity of the overall context that demands mark-up rather than code lines for editing purposes. Editing, writing of all kinds, even if the end product is not to be XML, then XML as a structuring device is very important, I would go as far as saying logically inescapable. Unlike any form of code it is naturally passive, it is just mark-up (problems are created when XML is pushed to do more =96 it doesn't like it and you get a mess). I would suppose everyone reading this treats their line-editors as a natural extension of themselves while coding. Simple and robust technology with a lot of useful features added on top. Some of the more syntax sensitive ones are using XML-like structuring by scanning for markers in the code being written. With experience, line editors work well, but without such experience the problems with handling code this way becomes overwhelming, because, in essence, it is so damn primitive and code is not. However, for anyone who has used any of the current XML editors, the opposite is true. The things are so damn complex using them in the everyday sense would be mental suicide and a productivity blow almost beyond recovery. There problem is not additive, like line editors being simple and then having features piled on them, it is fundamental miss-design. They are in effect not XML editors at all, but tag editors. Tag obsession is a symptom of missing the point of XML. Tags are human determined mark-up rendered in machine readable form. XML itself is not easy to read by human beings, it is possible to make sense of the tags by looking at what they mark-up, but you can no more =93read=94 a complex XML document (like TEI mark-up) than read a text sprinkled with gibberish. Using tags to make up XML documents is silly and always has been, people only really do it because they have no other choice. For instance: The Text Encoding Initiative (TEI) scholarly mark-up of all kinds of Literature means hand placing a massive number of tags into a text. This is done because it is an important way to access text through its tags, annotate them, and reference them sanely. Marking-up for TEI even with the much improved tools of the last few years =96 is simply insane. Yet the very fact that academics do it at all, says much about the power of XML when applied to something as complex as Literature. The trick is a simple one =96 the rules of tag use have to be readable even if produced by a GUI. A DTD has to read as prose, it is not just the instructions for what follows what, but also a description of the type of document being constructed, something human beings have to read, especially when they are deciding whether the document design actually does fit what they have in the text. I mentioned Ultra-Verbose Generated Scripts in an early post. tag <p> does not actually convey much in itself, but a Verbose dialect says it all: =93The tag 'p' is used for a paragraph that can include...=94 It is simple prose, extremely verbose, giving us a help file but also important resources =93p=94 is the tag, but it is in plain language a =93paragraph=94 which is more useful in menus than =93<p>=94. A REBOL dialect for DTD description has to be verbose because in the end people have to read it simply to see if it fits what they want to do, or needs more put into it or deleted. Using tags in that script adds structure for editing purposes, and penalties in processing, but also a display for printing, or screen reading, as well as editing via stylesheets. That is the second trick. Human beings should not deal with tags at all, the tag rules should shape the stylesheet and in effect the stylesheet marks the text. Applying a stylesheet to text, changes its look, but also changes its tags. If applying =93new Paragraph=94 to a chunk of text, may do no more than add a space between it and the rest of the text, but it may also eliminate needless line returns and add in <p> ... </p> to make this explicit. My stylesheet for editing should not resemble the final presentation stylesheet, it has a different purpose. I can have for instance have =93dates=94 in bright pink, underlined in red and with an explanatory supertext in a double spaced edit document. That is the colour makes it easier to see whether I have got all the dates, while the fact that some are Julian dates and others Islamic dates is explicitly shown, but none of this will be shown in the final document. Editing is one environment, what is produced is another. Every Word Processor confounds this difference, and I would argue why many reading this much prefer a line editor than a WP to write their code. And that amongst many others is a problem that needs an elegant solution the solution is not to have several different editors, but essentially one editor that can be presented in a myriad of different ways. For that to work the elements, aside from actual GUI features, boils down to a stable mark-up structure and dynamic graphical stylesheets through which editing is done =96 the rest is simple translation of formats. --- Message Received --- From: Carl Read <> To: Reply-To: Date: Sat, 8 Sep 2007 20:23:45 +1200 Subject: [REBOL] Re: - R3 GUI No need to apologise for your posts Greg - they're good and interesting and probably very pertinent to REBOL. BTW, have you read Carl Sassenrath's posts on XML/CSS? They're here... And the follow-up post... -- Carl Read. On Saturday, 8-September-2007 at 15:21:15 greg.schofield wrote,
>I apologise to the list, but I cannot help but add more on a slightly dif >ferent aspect of my previous post. > >And I must add a strange rider on oddities in how I am presenting things. > >1) I have not attempted to learn REBOL yet, let alone script with it, in >fact I am confining myself to reading about it. > >2) I will learn REBOL from the basics up when R3 appears, the reason is s >imple, I intend to write a conceptual introduction to REBOL, based on wha >t I learn in practice, as I am leaning it (for the simple reason that cap >turing the moment of understanding soon escapes when the knowledge is est >ablished, I need to make notes as each idea sinks in rather than try and >reconstruct it inaccuratetly - I believe REBOL is significantly different > from other script langauges and that there is a gap in documentation tha >t needs to be filled).
[rest snipped]