探索 XML 的替代语法 ―― 阅读和思考

非常棒的文章！它涉及我一直以来考虑的问题，如何简化xml的编辑（它明确指出了我未确切意识到的xml编辑困难的一个根源：即最商业化的XML编辑器也在一定程度上需要定位和点击，这成为快捷自由地编写内容的拦路虎）。
与wiki一样，更简洁的超文本语言也是我早期naxt项目尝试的出发点。实际上在中期，我已意识到即使我很严谨的切分出module/level，要保持一个一致的特性集合和语法，就需要对应用范围做更明确的限定。故现在我倾向于将naxt定义为xhtml2（或其子集）的一个等价的紧凑语法。这样避免对语义的过多纠缠。
在naxt项目的尝试中，我逐渐转向到编写通用的txt2xml文法解析器和转换器上。BTW，在把xml降格为特定领域的简单文本格式的同时，我所关注的另一条线路是特定xml编辑器的通用表达（而不是为每个方言专门以重量级语言写一个专门编辑器），例如我对把xforms作为一般化xml编辑界面定义语言具有极大期望。
继续，上文提到许多值得参考的设计（如非常成功的relax ng及其compact语法），特别是xsltxt。事实上，从第一次接触到resin的StyleScript，我也独自考虑xslt的紧凑语法久矣。这样我有以下可以借鉴的：xslt本身、XSLT-lite（StyleScript）, XSLTXT, XQuery, JXPath, GPath。当然，我还有设计上的重大问题没有考虑清楚，是否是直接的xslt对应，还是可以更接近一种独立的模板语言（比如允许破坏well-formed，甚至超出声明性允许副作用）？尽管已经出现了groovy这样的通用和便利兼顾的敏捷语言，但我觉得仍有必要考虑xslt的方案，因为它是标准，平台中立，广泛接受，具有最大程度的互操作性（因此需要谨慎处理副作用这样的扩展），而且有独特而强大的“模板自动应用”。一般模板技术不具备这种抽象机制。
文章的结语提出了一些重要的问题，这是我已经意识到或尚未意识到的困扰和原则。
……压缩语法的不足是丧失了互操作性和能否经得住时间的考验。多数成果都来自于单独的第三方。还不完全清楚对千差万别的字符编码以及那些很少使用的 XML 成分（比如处理指令）提供什么样的支持。另外，多数情况下它们都只存在一个创始人，因此其想法很可能逐渐消亡。