Carl thanks for the pointers I have not read it before.Carl thanks for th= e references I had not read it before.
And thanks for the references I had not read them before: <http://www.rebol.com/article/0108.html> http://www.rebol.com/article/0110.html Interestingly, I agree with just about all of it. Yet, I had waited a long time for XML, (that is long before HTML, and bef= ore I had heard of SGML). But it is typical of the computer industry to m= iss the point, the articles are spot-on in their criticism. In a sentence: XML is excellent for marking up Literature - but useless f= or 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). Convertin= g REBOL scripts (ie data scripts especially) to XML is, unlike any other = language I know, a trivial thing. Unambiguously converting it back, is li= kewise trivial (there is a delay naturally). If I am using a REBOL rolladeck to keep my contacts, I don't want to repr= oduce it in parts when I need sections of its elsewhere, ideally I want i= t in one place in a form that suits its use (ie in passive saved form, tr= anslated 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 thi= ngs when perhaps I have made a systematic mistake, the easiest path may w= ell 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 W= ord 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 gene= ral it should be passive (have things done to it) rather than as an activ= e agent. Another simple rule is generally XML is good when the content fa= r outweighs the tag lengths, but not always, sometimes it is the complexi= ty of the overall context that demands mark-up rather than code lines for= editing purposes.=20 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 pas= sive, it is just mark-up (problems are created when XML is pushed to do m= ore =96 it doesn't like it and you get a mess). I would suppose everyone reading this treats their line-editors as a natu= ral extension of themselves while coding. Simple and robust technology wi= th a lot of useful features added on top. Some of the more syntax sensiti= ve ones are using XML-like structuring by scanning for markers in the cod= e being written. With experience, line editors work well, but without such experience the = problems with handling code this way becomes overwhelming, because, in es= sence, it is so damn primitive and code is not. However, for anyone who has used any of the current XML editors, the opp= osite is true. The things are so damn complex using them in the everyday = sense would be mental suicide and a productivity blow almost beyond recov= ery. There problem is not additive, like line editors being simple and then ha= ving 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.=20 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 t= ext. This is done because it is an important way to access text through i= ts tags, annotate them, and reference them sanely. Marking-up for TEI eve= n 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 powe= r 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 ev= en if produced by a GUI. A DTD has to read as prose, it is not just the i= nstructions for what follows what, but also a description of the type of = document being constructed, something human beings have to read, especial= ly when they are deciding whether the document design actually does fit w= hat they have in the text. I mentioned Ultra-Verbose Generated Scripts in an early post. tag <p> doe= s 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 simpl= e prose, extremely verbose, giving us a help file but also important reso= urces =93p=94 is the tag, but it is in plain language a =93paragraph=94 w= hich 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 structu= re 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 ma= rks the text. Applying a stylesheet to text, changes its look, but also c= hanges 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 m= ay also eliminate needless line returns and add in <p> ... </p> to make t= his explicit. My stylesheet for editing should not resemble the final presentation styl= esheet, it has a different purpose. I can have for instance have =93dates= =94 in bright pink, underlined in red and with an explanatory supertext i= n a double spaced edit document. That is the colour makes it easier to se= e whether I have got all the dates, while the fact that some are Julian d= ates 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 Proce= ssor confounds this difference, and I would argue why many reading this m= uch prefer a line editor than a WP to write their code.=20 And that amongst many others is a problem that needs an elegant solution = the solution is not to have several different editors, but essentially on= e 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 stabl= e mark-up structure and dynamic graphical stylesheets through which editi= ng is done =96 the rest is simple translation of formats. --- Message Received --- From: Carl Read <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] 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 a= nd probably very pertinent to REBOL. BTW, have you read Carl Sassenrath'= s posts on XML/CSS? They're here... http://www.rebol.com/article/0108.html And the follow-up post... http://www.rebol.com/article/0110.html -- 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 di= f=3D >ferent aspect of my previous post. > >And I must add a strange rider on oddities in how I am presenting things= .=3D > > >1) I have not attempted to learn REBOL yet, let alone script with it, in= =3D >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=3D >imple, I intend to write a conceptual introduction to REBOL, based on wh= a=3D >t I learn in practice, as I am leaning it (for the simple reason that ca= p=3D >turing the moment of understanding soon escapes when the knowledge is es= t=3D >ablished, I need to make notes as each idea sinks in rather than try and= =3D >reconstruct it inaccuratetly - I believe REBOL is significantly differen= t=3D > from other script langauges and that there is a gap in documentation th= a=3D >t needs to be filled). [rest snipped] --=20 To unsubscribe from the list, just send an email to=20 lists at rebol.com with unsubscribe as the subject. -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject.
