我一直认为XML(以及之前的SGML)数据是魔鬼的格式.我是旧数据库和平面文件学校.尽管如此,我们正在开发一种商业化的Web产品,其框架基于链中的XML数据转换/转换.
当我们正在采访职位以及与潜在客户交谈时,他们喜欢它会做什么的概念,但却厌倦了长期支持XSLT.有人甚至称之为众所周知的"死".死了像COBOL,Unix和C还是像Apple Business BASIC一样死了？
无论如何,我很好奇,如果在XSLT上构建一个Web框架对于公司来说真的不够(奇怪). 是否存在固有的XSLT实施问题,使这个风险值得重新考虑？
现有的基于XSLT的Web内容管理系统(如Umbraco和Symphony(这里已经提到过))的普及为XSLT对Web框架的适用性提供了很好的证据.
如果有的话,XSLT正在上升.很高兴看到成熟的XML解决方案公司仍然在数量上采用它,例如,MarkLogic不久前就在其XML数据库产品中添加了XSLT功能.
在W3C最后呼吁XSLT的3.0工作草案发表在2013年12月,显示XSLT未来的持续关注和投资.
XSLT(和XQuery)也有一些有用的新开放标准扩展,例如EXPath项目,其功能库包括广泛的HTTP和Zip功能.
[更新]随着Saxon-CE(现在开源)的推出,XSLT 2.0处理现在可以在服务器端和客户端完成.它还可能为以前仅限于XSLT 1.0的框架提供2.0功能.
Saxon-CE中的语言扩展意味着XSLT模板现在可以使用简单的XPath和"事件模式"绑定到用户事件,在需要时还有更好的JavaScript互操作性.
如果您的应用程序依赖于转换 XML 数据，那么无论如何，这就是 XSLT 的专用用途，并且它做得很好，只是代码可能相当冗长。
我从未真正听到过有关 SAXON 作为 XSLT 实现的问题的抱怨。
也许研究 SXML、SXSLT、SXPath 等值得考虑。
就 XSLT 的消亡而言，我注意到它仍在攀升，并没有真正超过其顶峰，尽管我确实注意到越来越多的声音开始看到 XML 中的设计缺陷，但对我来说，将 XML 用作数据存储格式是一个不寻常的决定XML 是一种很好的数据表示格式，尤其是在 Web 上，作为传输信息的容器也很冗长，但它确实可以表示信息。
不过，XML 确实存在某些人所说的设计缺陷。
| 归档时间： |
|
| 查看次数： |
2903 次 |
| 最近记录： |