[
Lists Home |
Date Index |
Thread Index
]
Norman Gray wrote:
> there's a practical matter of, say, how many
> XSL templates you can see on your screen at
> once; and with a verbose syntax like instance
> syntax, the answer is `not many'.
There was much human factors research back in the 80's
concerning the impact of screen size on productivity and bug counts.
Almost all of it indicated that there was a direct inverse
relationship between screen size and bug counts. In other words, the
smaller the screen, the larger the number of bugs. Also, the inverse,
the larger the screen, the higher the productivity. The basic premise
seemed to be that larger screens allowed more context to be displayed
-- thus, understanding was improved. Compact syntaxes would seem to be
measures to increase the amount of context without increasing the
amount of screen space.
> This is why, in suitable contexts, compact=readable.
> This is why RNC compact syntax is more readable
Compact is not always "readable". For instance, APL, Forth,
even Hebrew (which omits vowels in common usage...) are often put
forth as examples of compact syntax, however, they can't really be
presented as very readable. Compact syntaxes often require the reader
to do a great deal of mental context maintenance or pattern matching.
There is no inherent relationship between terseness and readability.
Of course, it is important to remember that the goal often
cited for XML is that it be merely "readable" -- not "easily read",
etc. And, this mere "readability" is supposed to be in the context of
debugging or otherwise watching data in action. What amazes me
sometimes is that people can't see that a syntax that might be useful
because it is "readable" on-the-wire might be less-then-ideal for
editing and every day use.
When building useful systems, we constantly alter the
presentation format for data depending on the specific context. It is,
in fact, the provision of alternative representations that is at the
core of many useful applications. For instance, when I work with
tables of numbers, I often use an Excel spreadsheet to do so. The
numbers are presented to me as glyphs arranged in rows, etc. However,
on-the-disk or on-the-wire, my spreadsheets are encoded as XML or as
Microsoft specific binary blobs. But, while I might use the XML form
for interchange with other application or occasionally for debugging,
it just wouldn't be a "spreadsheet" if the editing interface exposed
only XML. The same applies to other formats. e.g. If I'm in a document
editor, I want to see bold text, underlines, etc. I want to see "very
readable" stuff. The fact that my data can be stored as "merely
readable" is a nice thing. But, only relevant in the exceptional case.
There are a great many people who spend a great deal of time
editing XML, XSL, etc. directly when it is simply unnecessary. An
editor should present data in an easily understood, easy to edit form.
How an editor stores or interchanges data shouldn't impact the syntax
of the interface, only the semantics which are exposed.
bob wyman
|
