Makes XML much less vulnerable to mismatches like dropping a paren:
<A> <B> <C> <D> ... </D> </B> </A> - the missing </C> can be inferred, and possibly even repaired
(A: (B: (C: (D: .... ) ) )
which closing paren is missing? A, B, C, or D's?
But... sometimes I end up editing XML by hand. (Like on a wiki. (Or in blogger :-( ) And sometimes typing <longname>...</longname> is just too much.
Sometimes I would like the option of having a more compact, but less robust, bracket notation. Like the above mentioned (A: ... )
Or [A: ... ]. Or {B: ...}. Or
Consider
<A> (B: {C: [D: ... ] ) </A>
it is still pretty easier to infer that the closing } for {C: is missing.
Here's a thought: the matchingness of brackets is orthogonal to the actual name of the construct that uses the bracket - in XML parlance, the element.
LISP dialects that use only parens ( and ) exclusively are at one end of the spectrum.
XML, with arbitrary <tag> ... </tag> is at the other end.
And in between, we can have notations that use matching { and }, [ and ], < and >, << and >> - heck, Perl and regexps show that there don't even need to be matching pairs. ' and '. " and ". Or ‘ and ’, etc.
These could be intermixed, as I have done before.
Indeed, the same entity, the same statement type, could use either bracketing form: <A> (A: ... ) </A>
I can imagine tools that translate between these forms.
From XML: <A> <A> ... </A> </A>
To strictly lisp-like parens: (A: (A: ... ) )
To forms that employ multiple bracket types for "clarity": (A: {A: ... } )
---
I guess that I am using (A: ...) as the compact representation of <A>...</A>.
Q: what about attributes? (A at1="at1" at2="at2" ... : ...)
---
There seems to be little lossage here. Except for the lost opportunity to place attributes on closing XML tags, <tag attributes>...</A closing-attributes> --- something that XML does not allow, but which I have supported in my own pseudo-XML dialects.
