好吧这有点令人尴尬,但我不确定XML的用途是什么.这是正确的XML意味着什么,而不是什么是XML.我现在使用XML多年来主要用于配置文件,但这似乎是一个微不足道的用途.我也将它用作数据文件的互操作格式,但对我来说它看起来并不是特别有效.我对Web开发的经验很少,所以我认为它可能对通信很有用,但我读到的关于XML的大部分文章实际上是XML和JSON之间的比较,而不是XML本身.
更新:到目前为止,我的感觉(基于这个评论)是XML用于通用数据传输,但在最初的兴奋之后由于其低效性而受到青睐(并且它是低效的,因为它是通用的)进一步的想法受到欢迎.
Gáb*_*ták 11
我尝试总结一下我使用XML的经验:
每个人都可以通过阅读它来检查其内容.这使其成为一种易于使用且易于理解的通信形式.甚至商界人士都喜欢它(就我多年来对金融机构的经验而言),因为他们理解它,并且他们可以轻松地在消息传递系统中检查消息.只有他们才能决定哪个系统是错误的.让他们开心:)与JSON比较.我认为JSON远非读者友好,因为关闭括号比关闭XML中的元素更难跟踪.你必须回头看看是什么开始.您不需要任何编程技能来理解XML.甚至你的祖母也可以在半小时后理解它.
无论你使用什么类型的语言和平台,你肯定会有一个解析器来阅读它.这使它可能是异构系统之间最好的通信形式.看到人们通常通过JMS队列传输XML,他们将XML发送到Web服务,他们在传输之前将对象映射到XML文档.XML是如此基本的东西,不同的解析器没有大问题.他们都了解XML.
您可以使用XSL和XSL-FO将XML文档转换为几乎任何内容.HTML,PDF,TXT,CSV,其他一些XML文件等.XSL非常强大,因为它可以根据XML的思路进行调整.它让你觉得递归,我总是喜欢在面向对象编程后很有趣.XSL几乎适用于任何平台.您可以使用XSL从纯数据创建报表和文档.您可以使用JAXB等技术轻松地将XML文档映射到编程对象.
XSD使您能够为XML文档定义一些语法.模式本身不像XML那样用户友好,但最简单的结构如occourance,parenthood,attributes等易于理解和使用.所以这也是一个工具,对商务人士来说可能是好的.XSD几乎适用于任何平台.
这两种技术都可以让您遍历和查询XML.优点与XSL和XSD相同,它们与平台无关.XPath是如此有效,即使对象树apache创建了相当于它:JXPath.
它可以占用任何磁盘空间.XML使日志变大,难以读取和获取.另一方面,您可以压缩日志.甚至可以压缩Web服务或JMS消息以减少通道的负载.但即使在这种情况下,压缩也是CPU和内存开销.另一方面,根据我的经验,XML和相关技术可以缩短开发时间,并且您节省的费用远远足以购买一个CPU.CPU比人便宜.
什么样的对象(XPath表达式,XSL模板,XSD架构,XML解析器等)具有什么样的生命周期,这远非微不足道.什么可以缓存？很多人不正确地避免线程安全问题.这将导致你可怕的缓慢.我想强调的是,这不是技术问题,而是误用.很多人都被困在旧的DOM解析器上,这是一个丑陋的事情.他们在它上面抽象了一些层,并创建了用于XML处理的专有API,这很糟糕.继续,使用DOM4j或STAX或JAXB或任何标准.
许多公司使用XML创建了特定于域的语言或可怕的配置文件.由于它易于解析和遍历,因此他们甚至为这种全新的语言创建了解释器.语言被卡住了,从未创建过计划的开发工具.不要使用XML来制作程序.它不是用来的.不要在XPath中编程,因为它没有经过验证的设计时间.把事情做好.XML主要用于以某种标准形式传输数据.不要在XML中重新发明轮子.这将是一个程序化的轮椅为自己而不是一辆车.
我认为关于XML的最佳教程是在ZVON.如果需要,可以使用它们.
作为传递数据的常用形式.那是20世纪90年代,标记标签风靡一时!
有很多灵活性和强大功能,包括验证XML文件的能力; 但我觉得有趣的是,近年来出现了一些更轻量级的替代品(例如JSON).IE浏览器.对于大多数应用程序而言,能够以人类可读的形式轻松读取/写入数据似乎比所有验证内容更重要.