Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Fixing what's broke
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|
|||||||||
