Comment by sciurus | Hacker News Reader

Comment by sciurus | Hacker News Reader

Parent Full thread

The heart of his suggestions:

Remove the syntactic mess that is attributes. (You will then find that you do not need them at all.) Enclose the /element/ in matching delimiters, not the tag. These simple things makes people think differently about how they use the language. Contrary to the foolish notion that syntax is immaterial, people optimize the way they express themselves, and so express themselves differently with different syntaxes. Next, introduce macros that look exactly like elements, but that are expanded in place between the reader and the "object model". Then, remove the obnoxious character entities and escape special characters with a single character, like \, and name other entities with letters following the same character. If you need a rich set of publishing symbols, discover Unicode. Finally, introduce a language for micro-parsers than can take more convenient syntaxes for commonly used elements with complex structure and make them /return/ element structures more suitable for processing on the receiving end, and which would also make validation something useful. The overly simple regular expression look-alike was a good idea when processing was expensive and made all decisions at the start-tag, but with a DOM and less stream-like processing, a much better language should be specified that could also do serious computation before validating a document -- so that once again processing could become cheaper because of the "markup", not more expensive because of it. But the one thing I would change the most from a markup language suitable for marking up the incidental instruction to a type-setter to the data representation language suitable for the "market" that XML wants, is to go for a binary representation.

He basically suggest turning XML into s-expressions. Eg.

    <p>Hello, <a href="http://example.com">world</p>

Turns into something like:

   <p "Hello," <a <href "http://example.com">"world">>

Not an obvious win as far as I can tell, wouldn't like to fix an ummatched bracket in a document ending in >>>> rather than e.g. </form><div></body></html>. But your mileage may vary.

His other ideas have more or less been implemented, with varying success. XML-Schemas have been introduced which is more powerful that DTD's. Some schema languages can indeed do complex computations for better or worse.

The macro-expansion approach is how XSL-formatting worked, and it turned out it was not as powerful or elegant as the CSS approach. It made sense when coming from a publishing background, but didn't predict dynamic interactive web pages.

"Not an obvious win as far as I can tell, wouldn't like to fix an ummatched bracket in a document ending in >>>> rather than e.g. </form><div></body></html>. But your mileage may vary."

HTML would then be an acronym for Lots of Irritating Single Angle Brackets.

This is an interesting issue

<p>blah</p> is easier to 'see' than <p"blah">

But in a big HTML you'll still be lost if you don't use indenting or a tool. At the end of the file you'll still have several close-tags one way or the other

One way would be to rewrite this in an easier way (but less canonical). In math there are several ways of doing that, for example:

Operator precedence and some defaults simplify, so you can write 3+2x(3+4) instead of (3+(2x(3+4)))

But it would probably make things worse for a text markup language.

Edit: changing asterisks for x

Hm, my immediate thought was that it would be written like TeX, e.g.:

    \p{Hello, \a[http://example.com]{world}}

This doesn't quite match what he's saying but I think it's a little more readable than your version.

I think he's more suggesting that XML is a fail because it attempts to take patterns that were designed (and work well) for document markup, and just mindlessly apply them to a very different task - data definition.

XML's totally fine for markup. It's also totally fine for situations where the primary content of the file is the XML tags themselves. For example, it's got its share of irritating gaffs but overall I'm rather fond of XAML as a way to define user interface layout.

But I've also seen a lot of monstrosities in XML. Situations where the tags themselves comprise 80% of the file, and yet are almost entirely redundant. Situations where the markup primarily serves to obfuscate the data itself. Situations where a file format changes to XML, bringing about a switch to routines that use an off-the-shelf XML parser. . . that still manage to consume twice as many lines of code as the from-scratch custom parser they replace.

> Not an obvious win as far as I can tell

How ironic, then, that you got the brackets right on the second one but not the first one.

Adding extra quotes and spacing confuses the issue needlessly, too.

The attack on attributes was my favorite parts. Attributes are indeed a moronic mess.

Too bad he neglected to similarly attack namespaces.

Reply on news.ycombinator.com