当前位置：编程学习 > C#/ASP.NET >>
答案：非常棒的文章！它涉及我一直以来考虑的问题，如何简化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 成分（比如处理指令）提供什么样的支持。另外，多数情况下它们都只存在一个创始人，因此其想法很可能逐渐消亡。
……不要忽视 XML 1.0 的互操作性及其对网络带来的影响，这些是 XML 的主要价值所在，也是使我们走到今天这一步的主要原因。
……在通用的 XML 替代语法之外，特定于应用的非 XML 语法似乎有更大的价值，特别是在那些需要创建大量内容的地方。……但是在易于编辑方面有一个合理的权衡。RELAX NG Compact 是一个很好的例子，说明了非 XML 语法确实能够揭示语言的底层概念和数据结构的秘密……
易于创建内容仍然是我所见过的有关使用替代 XML 表示最激烈的争论。编辑器开发似乎是计算中最棘手的难题之一，而且很少能找到帮助。
阅读和思考之后，我首先还是应该重写一个一般的txt2xml工具。不过这之前就要先定义一种表示文本文法的语言。之前我已经考虑许多类似工具，特别是以xi等几个以xml语法定义的rules，但是现在我猜测也许可以在某种程度上直接使用rng？
路还很长……
