HTML6, JSON SXML Simplified

What is wrong with XHTML/HTML5 exactly?

The politics of standard body changes, and their attitude about what is correct also changes unpredictably. In around 2000, we are told that XML and XHTML will change society, or, at least, make the web correct and valid and far more easier to develop and flexible. Now it's a decade later. Sure the web has improved, but as far as HTML/XHTML and browser rendering goes, it's still syntax soup with extreme complexities. 99.99% of web pages are still not valid, and nobody cares. Google doesn't care. Apple doesn't care. In Google's hundreds of tips to webmasters, none of it ever advocates HTML validation. Google Earth itself generates invalid KML. Some 99.9% of the HTML files produced by Google or Apple are not valid HTML. Major browsers still don't agree on their rendering behavior. Web dev is actually far more complex, involving tens or hundreds of tech that hardly a person even knows about (ajax, JSON, lots XML variations). It's hard to say if it is better at all than the HTML3 days with “font” and “table” tags and gazillion tricks. The best practical approach is still trial and error with browsers.

And, now HTML5 comes alone, from a newfangled hip group primarily from current big corporations Google and Apple, with a attitude that validation is overrated — a insult to the face about the XML mantra from w3c, just when there starts to be more and more sites with correct XHTML and Microsoft's Internet Explorer getting on track about correctness.

For some personal story about how the change of standard body attitude effect practical programing, see:

• Google Earth KML Invalid
• Google's nofollow Rule
• HTML Correctness and Validators

Why not just adopt SXML from the lisp world?

Lisp's SXML is not a stand-alone syntax for the need of the web. SXML's syntax is designed to be compatible with lisp lang's existing syntax. Lisp syntax (aka sexp) has several syntactical irregularities. It is not 100% of nested paren of the form (a b c …). SXML is easy for lispers to adopt, but harder for other languages and communities. (For detail of lisp's syntax irregularities, see: Fundamental Problems of Lisp.)

The following are explanation on how several of lisp's syntax for XML breaks the tree-and-syntax structural correspondence that is inherent in XML.

XML as textual representation of a tree has a quirk, in that each node has this special thing called “attributes” (aka “properties”). The “attribute” is not a node of the tree, but rather, is a special info attached to a node. Here's a example HTML:

<h1 id="xyz" class="abc">A B C</h1>

The standard lisp syntax to represent attributes, adopted from lisp's similar concept of “properties” of lisp's “symbols”, is this:

(h1 :id "xyz" :class "abc" A B C)

The way this works is by creating a extra rule on the first char of a name. If the name starts with :, then that name is considered the name of a property, and the next element is considered its value. This special rule breaks a fundamental principle of XML syntax. That is, the syntactic structure of the source code no longer corresponds to the semantic structure. The semantics of the source code changes depending on the first char of a atom.

Another way to represent XML's attribute, adopted in some lisp code based on lisp's “alist” (aka associative array) syntax, is this:

(h1 ((id . "xyz") (class . "abc")) A B C)

This too, has syntactical ambiguity.

From purely syntactical analysis, the whole ((id . "xyz") (class . "abc")) can be interpreted as a node by itself, where the first element is again a node.

But also here, it uses lisp's special “cons” syntax (id . "xyz") which is itself ambiguous at the syntax level. It can be considered as a node named “id” with 2 branches . and "xyz", like this:

id
 .
 "xyz"

or it can be considered as a node named “cons” with 2 branches id and "xyz", like this:

cons
 id
 "xyz"

Another common lisp syntax for attributes, from SXML, is this:

(h1 (@ (id . "xyz") (class . "abc")) A B C)

Here, again a special rule is created. When the first element's name is just “@”, then that parenthesized expression is considered to be a property list, not a node.

So, in conceiving HTML6, a solution for getting rid of syntax ambiguity for node vs attributes is to use a special bracket for properties/attributes of a node. For example, 〔h1 「id “xyz”, class “abc”」 A B C〕. This is a pure syntactical solution.

Why use weird Unicode characters for brackets?

Unicode is widely adopted today and is very practical. [see How Popular is Unicode UTF-8] It is the default char set for many langs (For example, Java, XML, Haskell, GoLang). Unicode also has a lot proper matching pairs. [see Matching Brackets in Unicode] Today is a good time to adopt the wide range of proper symbols provided in Unicode, instead of relying on the very limited number of ASCII characters of the 1960s.

The straight double quote character " (ASCII 34) is not a matching pair; it has several practical problems when used in a computer language. For example, it needs context to know which quote chars are paired. Also, it is difficult to recover from a missing quote. (this problem is especially pronounced in text editors for syntax highlighting.) A proper matching pair allow programs and editors to more easily correctly determine the quoted string, and thus easier to know its position in a tree, and makes it easier to implement features such as navigating the tree in a editor. (For more detail, see: Problems of Symbol Congestion in Computer Languages; ASCII Jam vs Unicode.)

The problem of inputting special chars of Unicode can be trivially solved by text editors. For example, Emacs, Mathematica, Microsoft Word, all have simple and efficient ways to enter commonly used special chars such as « ™ © é ¶ “” π ».

If we use ASCII brackets () and [] for HTML6, then it means a lot ugly escape will need to happen in the content text.