{"id":5280,"date":"2012-05-06T00:18:13","date_gmt":"2012-05-05T16:18:13","guid":{"rendered":"http:\/\/onthe8spot.com\/?p=5280"},"modified":"2012-05-06T00:18:13","modified_gmt":"2012-05-05T16:18:13","slug":"erik-naggums-xml-rant","status":"publish","type":"post","link":"http:\/\/onthe8spot.com\/index.php\/2012\/05\/06\/erik-naggums-xml-rant\/","title":{"rendered":"Erik Naggum's XML rant"},"content":{"rendered":"

| And how would you improve on it?
\nA brief summary, then: Remove the syntactic mess that is attributes.
\n(You will then find that you do not need them at all.) Enclose the
\n\/element\/ in matching delimiters, not the tag. These simple things
\nmakes people think differently about how they use the language.
\nContrary to the foolish notion that syntax is immaterial, people
\noptimize the way they express themselves, and so express themselves
\ndifferently with different syntaxes. Next, introduce macros that
\nlook exactly like elements, but that are expanded in place between
\nthe reader and the “object model”. Then, remove the obnoxious
\ncharacter entities and escape special characters with a single
\ncharacter, like \\, and name other entities with letters following
\nthe same character. If you need a rich set of publishing symbols,
\ndiscover Unicode. Finally, introduce a language for micro-parsers
\nthan can take more convenient syntaxes for commonly used elements
\nwith complex structure and make them \/return\/ element structures
\nmore suitable for processing on the receiving end, and which would
\nalso make validation something useful. The overly simple regular
\nexpression look-alike was a good idea when processing was expensive
\nand made all decisions at the start-tag, but with a DOM and less
\nstream-like processing, a much better language should be specified
\nthat could also do serious computation before validating a document
\n— so that once again processing could become cheaper because of the
\n“markup”, not more expensive because of it.
\nBut the one thing I would change the most from a markup language
\nsuitable for marking up the incidental instruction to a type-setter
\nto the data representation language suitable for the “market” that
\nXML wants, is to go for a binary representation. The reasons for
\n\/not\/ going binary when SGML competed with ODA have been reversed:
\nWhen information should survive changes in the software, it was an
\nimportant decision to make the data format verbose enough that it
\nwas easy to implement a processor for it and that processors could
\nliberally accept what other processors conservatively produced, but
\nnow that the data formats that employ XML are so easily changed
\nthat the software can no longer keep up with it, we need to slam on
\nthe breaks and tell the redefiners to curb their enthusiasm, get it
\nright before they share their experiments with the world, and show
\nsome respect for their users. One way to do that is to increase the
\ncost of changes to implementations without sacrificing readability
\nand without making the data format more “brittle”, by going binary.
\nOur information infrastructure has become so much better that the
\nnature of optimization for survivability has changed qualitatively.
\nThe question of what we humans need to read and write no longer has
\nany bearing on what the computers need to work with. One of the
\nmost heinous crimes against computing machinery is therefore to
\nforce them to parse XML when all they want is the binary data. As
\nan example, think of the Internet Protocol and Transmission Control
\nProtocol in XML terms. Implementors of SNMP regularly complained
\nthat parsing the ASN.1 encodings took a disproportionate amount of
\nprocessing time, but they also acknowledged that properly done, it
\nmapped directly to the values they needed to exchange. Now, think
\nof what would have happened had it not been a Simple, but instead
\nsome moronic excuse for an eXtensible Network Management Protocol.
\nAnother thing is that we have long had amazingly rich standards for
\nsuch “display attributes” as many now use HTML and the like. The
\nchoice to use SGML for web publication was not entirely braindead,
\nbut it should have been obvious from the outset that page display
\nwould become important, if not immediately, then after watching what
\npeople were trying to do with HTML. The Web provided me with a much
\nneeded realization that information cannot be \/fully\/ separated from
\nits presentation, and showed me something I knew without verbalizing
\nexplicitly, that the presentation form we choose communicates real
\ninformation. Encoding all of it via markup would require a very
\nfine level of detail, not to mention \/awareness\/ of issues so widely
\ndispersed in the population that only a handful of people per
\nmillion grasp them. Therefore, to be successful, there must be an
\nupper limit to the complexity of the language defined with SGML, and
\none must go on to solve the next problem, not sit idle with a set of
\ngreat tools and think “I ought to use these tools for something”.
\nStultifying as the language of content models may be, it amazes me
\nthat people do not grasp that they need to use something else when
\nit becomes too painful to express with SGML, but I am in the highly
\nprivileged position of knowing a lot more than SGML when I pronounce
\nmy judgment on XML. For one thing, I knew Lisp before I saw SGML,
\nso I know what brilliant minds can do under optimal conditions and
\nwhen they ensure that the problem is still bigger than the solution.
\n—
\nErik Naggum, Oslo, Norway
\nAct from reason, and failure makes you rethink and study harder.
\nAct from faith, and failure makes you blame someone and push harder.
\nvia Erik Naggum’s XML rant<\/a>.<\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":"

| And how would you improve on it? A brief summary, then: 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 … <\/p>\n

Continue reading “Erik Naggum's XML rant”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[79],"tags":[],"class_list":["post-5280","post","type-post","status-publish","format-standard","hentry","category-reposts"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"http:\/\/onthe8spot.com\/index.php\/wp-json\/wp\/v2\/posts\/5280","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/onthe8spot.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/onthe8spot.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/onthe8spot.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/onthe8spot.com\/index.php\/wp-json\/wp\/v2\/comments?post=5280"}],"version-history":[{"count":0,"href":"http:\/\/onthe8spot.com\/index.php\/wp-json\/wp\/v2\/posts\/5280\/revisions"}],"wp:attachment":[{"href":"http:\/\/onthe8spot.com\/index.php\/wp-json\/wp\/v2\/media?parent=5280"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/onthe8spot.com\/index.php\/wp-json\/wp\/v2\/categories?post=5280"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/onthe8spot.com\/index.php\/wp-json\/wp\/v2\/tags?post=5280"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}