Re: [xml-dev] Fixing what's broke

[rjelliffe <rjelliffe@allette.com.au>]

 On Fri, 10 Dec 2010 17:06:42 -0300, Max Toro <maxtoroq@gmail.com> 
 wrote:
>> <trajectory:initialVelocityVarianceCoefficient>1</>
>
> What is the value of this change ?

 An explicit end-tag on the same line as its start tag is noise.
 But closing brackets })] far from their open bracket {([ are confusing.

 IDEs and indention can help tame both (greying out end-tags, matching
 brackets). But they are not very reliable.

 But both add to the psychological complexity of reading the text.
 Terseness is good sometimes, but not good other times: XSLT
 trades on this by mixing XPath (a super terse language which
 becomes horrible when you get a lot of parentheses) and XML
 (a bracketed language for the high level constructs where
 start-tags may be screen-scrolls distant from end-tags.)

 People who mainly work with data structures with high fanout
 and deep nesting will find explicit tags better. People who mainly work
 with shallow data structures with low fanout will find brackets and ;
 better.

 So questions about which is absolutely better devolve
 into expectations about whether high fanout/deep nesting is better
 than low-fanout/shallow nesting. Which seems to me to be a question
 so abstract as to be almost meaningless outside specific cases.

 The value of the short end- tag </> is that if it prevents line 
 breaking on
 a screen or printing, you can fit twice as much of the information you 
 are
 interested in. For example, yesterday I printed out a 28 page 
 Schematron schema
 I have been working on for my job, for a testing system (where there is
 one phase for each test file, each phase mixing in the patterns 
 expected
 for that test file's results.)  Having a nice pretty-printed version
 is another tool in keeping things organized and being able to look-up
 what is going on: computer text that can be efficiently organized to
 print or render well helps you be a more effective developer. 
 Techniques
 for allowing developer effectiveness is a super important area, but not
 one where we can expect absolute statements like "this feature will 
 always
 allow everyone to be more effective". (In HUI terms, some kinds of 
 terseness
 in markup can act as an "affordance".)

 So what about this then: if the concern is that providing </> would 
 allow
 people to create obscure markup where you would have track back to see
 what the start was (the distant matching bracket problem), and assuming
 it is the job of a markup language design to enforce good practice in 
 the
 first place (hmmm), why not just allow the short end-tag </> to be used
 only on leaf elements?

 So
    <a>blah</>
 is allowed, but not
    <a>blah <b/>  blah </>


 Cheers
 Rick Jelliffe