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

[Max Toro <maxtoroq@gmail.com>]

You can use attributes if you find end-tags noise, or another format like JSON.
To me the end tag is crucial for readability, specially if you are
reading up instead of down.
--
Max Toro



On Sat, Dec 11, 2010 at 12:50 AM, rjelliffe <rjelliffe@allette.com.au> wrote:
> 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
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>