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

类别:.NET开发 点击:0 评论:0 推荐:

http://www-900.ibm.com/developerWorks/cn/xml/x-syntax/index.shtml

非常棒的文章!它涉及我一直以来考虑的问题,如何简化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?

路还很长……

本文地址:http://com.8s8s.com/it/it43479.htm