[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:
<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 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 <carl-cybercraft.co.nz>
To: rebolist-rebol.com
Reply-To: rebolist-rebol.com
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...
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 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]
