[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Readable syntaxes (was: XUL Compact Syntax Study Now Onli
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|