XML 2007年度回顾
上一篇 / 下一篇 2008-01-23 19:22:44 / 个人分类:XML
对XML来说,2007年又是发展较为平缓的一年。但是在这一年中,一些重要的规范都升级到了1.0版,XML在信息发布(Web和传统形式)方面得到持续发展。更重要的是,REST与Web服务的碰撞引起了轩然大波,整个Web服务领域产生了重大变化。引起这一巨变的最主要技术是POX(plain old XML),POX文档可以通过标准HTTP传送,而且不会被任何模式或规范羁绊(一些人在多年前就预感到这一结果,但是正如Roy Fielding所说,行业最终会亲自检验)。
REST并不是惟一隐含其强大功能的技术。XML的全部潜力也即将充分发挥。在这一年里,Atom发布协议(Atom Publishing Protocol,APP)和XQuery升级到了1.0版,而它们带来的影响才刚刚开始。
在过去十年中,XML经历了无数次挑战,不管是来自功能强劲的技术,还是来自名不符实的技术(YAML、SML、S-表达式,以及其他遭竞争淘汰的技术),但是2007年JSON的流行却是对它最大的挑战。尽管JSON的适用性有限、存在安全问题,而且应用程序编程接口(API)设计并不完善,但是这并没能阻碍它的进一步推广,明年其使用率似乎还会继续增长。
1月
在过去5年中,XQuery总是被认为是“下一年”就会实现的技术,这个承诺终于在1月份得以兑现,XQuery 1.0在1月正式发布。一些纯XML数据库已经实现了它,包括Mark Logic、eXist、Sedna和Berkeley DB XML。一些混合数据库也提供了对XQuery的支持,包括IBM® DB2® 9和Oracle
但是故事并没有就此完结。XQuery只是整个解决方案的一小部分。用CRUD的话来说,XQuery是不包含创建(Create)、更新(Update)或删除(Delete)的读(Read)操作。不得不通过专用的扩展来添加这些必需的功能。这意味着不能轻易地将一个应用程序或数据库从一个实现移动到另一个实现。更严重的是,开发人员不能使用标准语法,很难雇佣到经验丰富的Mark Logic程序员来处理DB2 9应用程序(程序很少在平台之间转换,但是开发人员经常这么做)。XQuery需要一个更新(和创建、删除)工具。World Wide Web Consortium (W
在这一年中,XQuery工作组也发布了第一批XQuery 1.1需求。一些最重要的新功能可能包括异常处理、扩展函数、函数指针和/或lambda表达式。幸运的话,只需五六年时间就能实现这些功能。然而,最好在XQuery真正流行起来之前就开始实施,而且任何规范的的更改都需要几十年的努力,就像SQL、Fortran和C的情形一样。
尽管XQuery是一种完整的编程语言—它可以完全取代PHP、静态HTML,以及任何其他Web框架—在不久的将来,您将需要将其与用传统语言编写的程序进行集成。因此在这一年提议将XQuery API for Java (XQJ)加入Java Community Process最终草案是一个很不错的主意。可将这看作JDBC for XQuery。Saxon 9和Data Direct XQuery 3.0已经提供了对XQJ的支持,而且一旦明年完整的规范发布,更多的供应商将会参与到其中。
2月
在最短也是最冷的2月,每个人都呆在家里,也没发生太多事情。Saxon、TagSoup和WebCGM都发行了新版本(您也许会问,什么是WebCG?)
在这个月,发布了XForms 1.1的last-call工作草案,其中添加了一些重要功能,包括对PUT和DELETE提交的支持。但是要使XForms成为最后的推荐标准,这一年剩下的10个月也许还看不到这一结果。11月最多实现XForms 1.1推荐标准。因此也许等到明年才能实现。
在这一年中,大多数主流XForms供应商都从不同角度发布了其产品的更新版本,包括FormsPlayer、Chiba、Orbeon,以及Mozilla XForms扩展。不幸的是,何时将XForms支持内置到主流浏览器中仍然难下定论。
3月
W
这一过程花费了两年时间,但是在3月份,W
尽管竞争激烈,2007年并没有产生多少实用的HTML 5代码。规范开发主要集中在Web视频、SQL API,以及解析arcana。将会在普通Web浏览器中实现哪种技术仍然是一个未知问题。对我个人而言,我怀疑在原生XML数据库在场外做热身时花费几个月时间开发一个浏览器内置的SQL API是不是明智之举(我答应这是本文中最后一次用足球做比喻,或者您可以拿走裁判员的口哨)。
4月
尽管早就有传闻XML将在Web中引入语义并使浏览器能够理解其显示的内容,但XML始终是关于语法,而不是语义。整个XML 1.0规范只包含两个和语义沾边的属性:xml:space和xml:lang(而且我不能肯定xml:space是不是语义属性)。在很大程度上,XML规范的意义来自于处理XML文档的应用程序,而不是文档本身。XML系列的后续规范也几乎是这样,包括名称空间、XML Infoset、XSLT,以及XPath。
但是在4月份,W
<xforms:model><dbk:article xmlns:its="http://www.w3.org/2005/11/its" xmlns:dbk="http://docbook.org/ns/docbook" its:version="1.0" version="5.0" xml:lang="en" its:dir="ltr"> <dbk:info> <dbk:title>Fun with XML</dbk:title> <dbk:author its:translate="no"> <dbk:personname> <dbk:firstname>Elliotte</dbk:firstname> <dbk:surname>Harold</dbk:surname> </dbk:personname> </dbk:author> </dbk:info> <dbk:para>XML rocks!</dbk:para> </dbk:article> |
此规范并未引起广泛关注,但它对在多种环境中进行发布的人(就目前而言,几乎包括所有人)来说非常有用。
在4月,W
- 最佳实践1:总是使用html标记属性声明页面文本的默认语言,除非文档包含针对使用多种语言的演讲者的内容。
- 最佳实践2:如果文档包含针对使用多种语言的演讲者的内容,决定是否需要在html标志中声明一种语言,或者不定义语言。
- 最佳实践3:如果文档包含针对使用多种语言的演讲者的内容,尝试根据最可能使用的语言对文档进行划分,并为每部分声明合适的语言。
- 最佳实践4:在文本中使用lang和/或xml:lang属性来指出语言上的任何更改。
- 最佳实践5:对于HTML,只使用lang属性;对于用作文本或html的XHTML 1.0,使用lang和xml:lang属性;对于用作XML的XHTML,只使用xml:lang属性。
- 最佳实践6:使用语言属性声明用于文本处理的默认语言,而不是使用HTTP或元元素。
- 最佳实践7:不要在body元素中声明文档的默认语言,使用html元素。
- 最佳实践8:如果属性值中的文本和元素内容使用的语言不同,考虑使用嵌入式方法。
- 最佳实践9:考虑在HTTP报头使用Content-Language声明或者使用元标记声明文档目标受众的语言元数据。
- 最佳实践10:如果文档包含针对使用多种语言的演讲者的内容,结合使用Content-Language和以逗号分隔的语言标记列表。
- 最佳实践11:遵循IETF的BCP 47中关于语言属性值的指导。
- 最佳实践12:使用尽可能短的语言标记值。
- 最佳实践13:如果可能,使用代码zh-Hans和zh-Hant分别指代简体中文和繁体中文。
- 最佳实践14:当指向另一种语言中的资源时,考虑指明目标文档语言的优缺点。
- 最佳实践15:如果希望指出一个元素的目标文档使用的是另一种语言,考虑结合使用CSS和hreflang的优缺点。
- 最佳实践16:不要使用标志图标指明语言。
5月
MathML是最初的几个XML应用程序之一,但遗憾的是它的实际应用有限。尽管如此,W
MathML 3最重要的功能是支持小学数学符号。毕竟,小学生比数学博士多得多,比例大概是100 000比1。MathML 3还添加了对双向布局的支持,并针对改良的排版对断行和定位方法进行了改进。最后,经过重写之后的规范条理更加清晰。我们希望第3次修改会更好。毕竟,Web是为数学而诞生的。
6月
在6月,OpenOffice Project发布了OpenOffice 2.2,这是一个跨平台的office套件,它将所有文件保存为国际标准OpenDoc格式的压缩XML文件。这几乎是一个bug修复版,不值得在一篇年度回顾文章中提及。但真正值得一提的是OpenOffice Project在发布针对Linux®和Microsoft® Windows®的版本的同时,还发布了第一个原生Mac OS X版本。
与Mac上以前的不完全版本(semi-releases)不同,2.2版基于Mac的原生Aqua用户接口工具箱,而不是X-Windows。虽然Mac版本只具有内部测试版品质(alpha quality),但仍然极大推动了OpenOffice,使其离成为Microsoft Office有力竞争者这一目标更进一步。如果OpenOffice能够吸引大量使用MacBook的编程人员,那么它最终可能消除自1.0版就存在的用户界面问题。
6月里也发生了与浏览器端相关的重大事件,Apple在这一月发布了Safari 3.0 forWindows的第一个测试版。Apple不再满足于6%(仍在增长)的市场份额,它似乎要在大后方向Microsoft发起全面挑战。首先是iTunes,现在是Safari?iLife和iWork还会很远吗?只有在2008年才能看到结果。同时,Safari支持XML、XSLT、Cascading Style. Sheets (CSS)、XHTML、Atom和RSS。Safari的CSS支持比任何其他Windows平台的浏览器都要好。由于被Google搞得心烦意乱,Microsoft可能未注意到Apple已经从后面偷偷赶上了。
7月
在7月,W
“EXI是eXtensible Markup Language (XML) Information Set的简洁表示,旨在同时优化性能和计算资源的利用率。EXI格式使用一种源于信息和正式语言理论的混合方法以及经过测量验证的实践技术对XML信息进行熵编码。使用相对简单的算法和一个小型的数据类型集合,前者有助于更快更紧凑的实现,后者能够可靠地产生有效的XML事件流编码”。
我不知道还有什么比这更糟:这种格式难以置信的不透明性,或者EXI实际上并不是XML信息集合表示的事实。不透明性我已经预料到了,但是后者大出我所料。EXI引入了数据类型,比如二进制、布尔值、小数、浮点数、整数、无符号整数,以及日期-时间。XML没有数据类型,而这只是一个特性,并不是一个bug。XML并未打算告诉任何读者它如何解释文档中的文本字符串,但EXI这样做了。
幸运的是,在年末,EXI在W
8月
在8月,XML研究者从法国转移到蒙特利尔,在这里举行了一年一次的Extreme Markup Languages会议。这是至今为止每年三次主要XML会议中最令人讨厌的一次。没有关于如何编写样式表或模式的培训。取而代之的是“A Web 2.0 ANSI SQL Transparent Native XML Nonlinear Hierarchical LCA Query Processor”和“Exploring intertextual semantics: A reflection on attributes and optionality”这样的主题。
这个会议总是经费紧张,发言者通常比付费的出席者要多。会议主办方往往在会议结束时才确定是否将再次举行会议,而每个人也在静观其变。很不幸,今年将不再举办此会议。2007年注定是Extreme的最后一次争论(尽管它比许多竞争者都更长久)。
但是随着旧的会议的结束,新的会议将会出现。Mulberry Technologies,从我注意到它开始就在几乎所有内容上使用Extreme,该组织宣布将于2008年8月12-15日在蒙特利尔举行Balisage: The Markup Conference。
“Balisage将会满足那些致力于满足拓宽标记应用领域的理论家或实践家的需要。所有内容都与标记相关:如何创建标记;标记的含义;分层与重叠;模拟;分类;转换;查询、搜索和检索;呈现和可访问性;构建能够使用标记的系统(或者使标记在更小的空间获得更快的性能)—简而言之,通过对信息进行标记产生的强大功能改变世界和Web。”
如果加拿大元继续与美元背道而驰,那么2008年对美国人来说不太划算,但对欧洲人和加拿大人确是个好时机。
9月
本年度最大的事件发生在9月,借助对Office Open XML格式的支持,Microsoft促成了International Standards Organization (ISO)各国成员的投票者注册活动。这次活动首先发生在瑞典,在瑞典,23个主要的小型Microsoft附属公司在最后关头加入了瑞典标准协会(Swedish Standards Institute),其中22个公司投票支持OOXML。其他国家级标准机构也吸纳了比往年更多的会员应用程序,其中大多数来自Microsoft的合作伙伴。以前未加入JTC 1/SC 34(ISO的附属委员会,大多数XML工作都在这里完成)的国家突然之间都加入了。
尽管Office Open XML获得了大多数选票(51-18-18),但它需要至少2/3的“正式成员”的支持,而且反对票不能多于25%。这两个条件它都不满足,因此该规范被返回到Ecma International进行评议。也许Microsoft可以改进该规范,从而在2月的重新审议中获得所需的选票,但是结果还不能确定。撰写本文时,MIcrosoft似乎不太愿意让ISO控制OOXML的改进,因此之前的一些赞成票可能会变成反对票。
为OOXML争取选票的努力也间接损害了一些其他不相关规范的利益,包括Document Schema Definition Languages (DSDL)。许多支持OOXML的新成员对其他工作组任务不感兴趣。一旦他们投出选票后,他们将会消失,因而在决议无关的和争议较少的问题时无法达到法定人数。
10月
Atom发布协议在10月发布。APP作为上传blog条目的简单格式登上了舞台,旨在取代像MetaWeblog和WordPress API这样的定制API。但是,在这一过程中,APP逐渐显示出越来越多的优势。
APP只不过是一个用于将内容发布到HTTP服务器的具有RESTf风格的、可伸缩的、可扩展的安全系统。一方面,它是一个纯协议,完全独立于任何特定的服务器和客户机。另一方面,由于它也属于HTTP,所以很容易在现有客户机和服务器上实现。
Web最初只是作为一个读写媒介。但是在最初的15年里,主要的投入都放在了读取功能上。浏览器吸引了所有人的目光,而创建工具却没人关注。页面编辑器很少,而且主要通过FTP传递到文件系统。直到现在,借助APP,编辑器才得以变得与浏览器一样丰富、功能强大且易于使用。
一些优秀的服务器软件(比如eXist原生XML数据库)已经开始使用APP,而且一些客户机也正在使用它。在即将来临的一年里,将会有更多的软件采用APP。在Web上发布内容将会变得与浏览内容一样简单。
11月
在11月,Mark Logic公开了MarkMail,这是一个用于与电子邮件存档文件交互的基于XQuery的站点。Jason Hunter这样描述它:
“每一封电子邮件都被存储为一个XML文档,并通过XQuery对其进行访问。所有的搜索、分面导航(faceted navigation)、分析计算,以及HTML页面呈现都是在一个单独的MarkLogic Server计算机上执行的”。
MarkMail目前索引了大约500个邮件列表,包括Apache邮件列表、与jdom有关的邮件、xml-dev等等。
自然地,人们使用此功能所做的第一件事就是搜索自己的知名度。在这个集合中,发贴最多的人(top human poster)一直都是Saxon届的名人Michael Kay(一些自动发送提交消息的Apache robots试图超过他);但是在xml-dev方面,讨论最多的主题是Len Bullard,有超过4,000封邮件与此相关。Len的大多数邮件都包含好几页的文章,这使得他更加受关注。
我在xml-dev方面排名第10,拥有1,014封邮件。要不是两年前我更换了邮件客户机,我可能会排在第9位。我的屏幕名称由“Elliotte Rusty Harold”更改为“Elliotte Harold”,而数据库就把它们当作两个人来处理。系统中还有一些其他bug。:-)
12月
IDEAlliance一年一度的XML 2007会议在12月初召开,这是本年度规模最大的一次XML展览。这次会议在波士顿举行。出席的人数有所减少,只有300余位与会者和15位展出者。
本次展出的大部分内容都是比较著名的技术,至少是中坚XML开发人员一直关注的技术。与去年一样,XQuery仍然是展览会中的明星,尽管XForms也非常引人关注。XProc、RDFa、OpenDoc、Office Open XML、Atom、APP和JSON也引起了不少人的关注。Web服务和任何与SOAP相关的技术的缺席惹人注意。除了“但是现在我们正转向REST”以外,我还没有听见过这方面的术语。
展览会上真正的新产品来自预料以外的厂家:Intel。尽管Intel在硬件方面更著名,但是它也开发能最大限度利用自己的处理器的软件。Intel在展会上展出并发布了Intel XML Software Suite,这是一个针对Linux和Windows的原生X86库的集合,提供了真正的快速XSLT处理、XPath评估、XML模式验证、文档对象模型(DOM),以及Simple API for XML (SAX)解析。其中还包括一个基于Java原生接口(Java Native Interface,JNI)的针对Java™平台的包装器。
Intel声称这个库的速度是XPath和XSLT的XSLTC和Xalan的两倍,而且比对大型(大于100MB)文档进行原始解析的Xerces-C++快6倍。解析器使用占用更少内存的符号表数据结构和跨两个或更多内核的多线程处理来实现这些性能。这个库可用于处理300 MB到32 GB范围的文档。对于更小的文档,由于这项技术开销比较大,所以传统解析器更快些。
我还没有机会验证Intel的宣称;但是如果这是真的,将非常有趣。Xerces并不是最快的解析器,但是6倍的速度提升是其他任何技术都还未达到的。令人惊讶的是,Intel使用标准API、SAX和DOM达到了这样的性能。对我个人而言,我非常相信XML解析性能能够提升,但是我以前以为需要专注于高性能的新API来实现。Intel似乎不需要这样做。
W
对于XML来说,2007年是多产的一年。主要的争论集中在office文档的标准化方面,这场战斗甚至引起了流行刊物的关注(有谁曾经在Wall Street Journal上阅读过关于XML格式的ISO标准的信息呢?)
但是如果我不得不挑选出今年发生的最重要的事件,我很难在正在缓慢成长的XQuery、APP和XForms之间做出选择。所有这些都有可能从根本上改变Web的底层软件基础结构。XForms是一个全新的客户机开发平台,XQuery是一个全新的服务器开发平台,而APP将二者连接起来。在三者当中,XQuery已能够应用于生产,而APP正在快速发展。在2008年,两者之间一定会发生重大事件。XForms紧跟其后,也许稍微有点落后,但是我希望它的发展不算太慢。总之,XML在Web上的前景要比以前更加光明。
导入论坛 引用链接 收藏 分享给好友 推荐到圈子 管理 举报
TAG:


