其实数年前已经不建议使用DTD了吧。而是推荐XML schema
2013-10-21 16:20
381 查看
其实数年前已经不建议使用DTD了吧。而是推荐XML schema。
XSL是转换XML文档用的。
其实XML主要的用途就是分离数据和使用数据的应用程序。专注于对数据本身的描述,不涉及数据如何使用的信息,如表示格式的说明。文件本身的格式是自说明的。于是XML数据文件就很通用,各种语言都可以实现其PARSER。跨平台加标准的PARSER,相当适合平台/应用间交换数据之用。过去我们搞过EDI,用UN/EDIFACT标准,还有部颁平面文件标准。后来一看XML就感觉这个东西的妙处了。
通用性都是通过在体系结构中加入额外的处理层,比如通过把数据和使用数据的应用程序分离开来,来达到的。XML正是处在这样一个额外的层上。这样带来直接的一个后果就是消耗额外的时间/空间消耗。因此XML不适合应用在对性能要求非常高的环境。PARSER的处理,内存的分配和垃圾处理等等,都会影响系统的性能。
另外XML设计就是纯文本文件。二进制文件当然可以通过编码做成XML文件,自然需要解码处理。
XML对标准要求非常严格。因为这个东西是设计用来交换数据用的,因此不能象HTML那样允许应用程序做扩展,或者允许各自决定错误处理方式。一个出错的HTML页面,IE和NETSCAPE还可以自行纠正格式并且展示出什么来,XML这是绝对不可以的。一旦XML文件里格式有错误,绝不可以让应用程序来决定如何纠错。因为这个文件本身,包括里面的数据,已经不可靠了。所以正常情况下,用XML的时候,不要自己去动手写PARSER。因为很容易在自己的PARSER里违反SPECIFICATION的规定,带来生成/读入错误XML数据文件的风险。使用JAVA的人一般都用API了,很多使用C/C++的人,都乐意自己去写XML的PARSER。这样相当危险,除非通读并完全遵循SPECIFICATION。
意见2:
XML作为一项能被项目经理关注的技术,目前主要的应用针对:
=======================================================
网页设计(使格式与数据分离),
软件配置文件(使用XML代替properties文件)
消息驱动系统中的消息载体(消息中间层传递XML)
数据交换(XML文件或XML信息流)
XML数据库(目前这一应用还在起步和发展阶段)
=======================================================
还应该有其他方面的应用,主要看项目的具体情况,Case by case.
其实针对XML的应用有国外一份权威的行业杂志:www.XML-Journal.com 大家可以抽空去看看,是英文的。
但这份杂志的文章都很有前瞻性和创新精神,发布XML应用的主流和有价值的技术知识、组织、标准和基于
XML的应用的商业信息系统等信息。
意见3:主要用在配置文件,web
services,跨系统的信息传递。
意见4:
XML最初提出的目标就是为了能够解决HTML的显示和数据不能分离的致命缺陷而提出的。XML+XSL就是为了解决这个问题。随着XML的深入推广,渐渐地就被很多系统交换信息而采纳。我觉得,可能基于以下几个原因:
1 规格化,XML的这种标记格式,本身就很容易用统一的代码来解析和生成,包括上面提到的一些开发工具(可以自动产生对应XML->编程对象的转换代码)都是由于这个原因。因此,不同系统间的数据接口开发和维护成本大大降低
2 各大厂商致力于标准的推出,SOAP就是最好的一例。使得Web Service已经等同于SOAP了。
3 在实际系统开发中,可以大大降低需求变动导致数据格式变化而产生的不利影响。因为XML本身就可以存储复杂的数据结构。
SOAP是一个基于XML的轻量级MESSAGING协议
只是WEB SERVICES的MESSAGING层的协议
上面还有服务描述层和服务,恩,定位层
说WEB SERVICES等同于SOAP可是不准确啊
SOA (SERVICE-ORIENTED ARCHITECTURE)的一个特色是FIND-BIND-EXECUTE PARADIGM
这个玩意可主要是在MESSAGING上面那两层实现的
XSL是转换XML文档用的。
其实XML主要的用途就是分离数据和使用数据的应用程序。专注于对数据本身的描述,不涉及数据如何使用的信息,如表示格式的说明。文件本身的格式是自说明的。于是XML数据文件就很通用,各种语言都可以实现其PARSER。跨平台加标准的PARSER,相当适合平台/应用间交换数据之用。过去我们搞过EDI,用UN/EDIFACT标准,还有部颁平面文件标准。后来一看XML就感觉这个东西的妙处了。
通用性都是通过在体系结构中加入额外的处理层,比如通过把数据和使用数据的应用程序分离开来,来达到的。XML正是处在这样一个额外的层上。这样带来直接的一个后果就是消耗额外的时间/空间消耗。因此XML不适合应用在对性能要求非常高的环境。PARSER的处理,内存的分配和垃圾处理等等,都会影响系统的性能。
另外XML设计就是纯文本文件。二进制文件当然可以通过编码做成XML文件,自然需要解码处理。
XML对标准要求非常严格。因为这个东西是设计用来交换数据用的,因此不能象HTML那样允许应用程序做扩展,或者允许各自决定错误处理方式。一个出错的HTML页面,IE和NETSCAPE还可以自行纠正格式并且展示出什么来,XML这是绝对不可以的。一旦XML文件里格式有错误,绝不可以让应用程序来决定如何纠错。因为这个文件本身,包括里面的数据,已经不可靠了。所以正常情况下,用XML的时候,不要自己去动手写PARSER。因为很容易在自己的PARSER里违反SPECIFICATION的规定,带来生成/读入错误XML数据文件的风险。使用JAVA的人一般都用API了,很多使用C/C++的人,都乐意自己去写XML的PARSER。这样相当危险,除非通读并完全遵循SPECIFICATION。
意见2:
XML作为一项能被项目经理关注的技术,目前主要的应用针对:
=======================================================
网页设计(使格式与数据分离),
软件配置文件(使用XML代替properties文件)
消息驱动系统中的消息载体(消息中间层传递XML)
数据交换(XML文件或XML信息流)
XML数据库(目前这一应用还在起步和发展阶段)
=======================================================
还应该有其他方面的应用,主要看项目的具体情况,Case by case.
其实针对XML的应用有国外一份权威的行业杂志:www.XML-Journal.com 大家可以抽空去看看,是英文的。
但这份杂志的文章都很有前瞻性和创新精神,发布XML应用的主流和有价值的技术知识、组织、标准和基于
XML的应用的商业信息系统等信息。
意见3:主要用在配置文件,web
services,跨系统的信息传递。
意见4:
XML最初提出的目标就是为了能够解决HTML的显示和数据不能分离的致命缺陷而提出的。XML+XSL就是为了解决这个问题。随着XML的深入推广,渐渐地就被很多系统交换信息而采纳。我觉得,可能基于以下几个原因:
1 规格化,XML的这种标记格式,本身就很容易用统一的代码来解析和生成,包括上面提到的一些开发工具(可以自动产生对应XML->编程对象的转换代码)都是由于这个原因。因此,不同系统间的数据接口开发和维护成本大大降低
2 各大厂商致力于标准的推出,SOAP就是最好的一例。使得Web Service已经等同于SOAP了。
3 在实际系统开发中,可以大大降低需求变动导致数据格式变化而产生的不利影响。因为XML本身就可以存储复杂的数据结构。
SOAP是一个基于XML的轻量级MESSAGING协议
只是WEB SERVICES的MESSAGING层的协议
上面还有服务描述层和服务,恩,定位层
说WEB SERVICES等同于SOAP可是不准确啊
SOA (SERVICE-ORIENTED ARCHITECTURE)的一个特色是FIND-BIND-EXECUTE PARADIGM
这个玩意可主要是在MESSAGING上面那两层实现的
相关文章推荐
- 常见sql
- 我的centos6.2无线驱动安装--- 一路还很顺
- 在打包项目时出现java:1: illegal character: \65279问题的解决方法
- C++虚析构函数
- 《健康地奋斗着——程序员自己的养生书》作者:中医程序猿
- 银行调度业务系统
- C# button重绘
- 触发器 orcale 代码 和 添加 字段 和注释 和 常见sql
- JFIF图片
- 费下载 !微软 Visual Studio 2013 and ASP.NET MVC 5 新特性体验课程
- 高级项目管理师
- 固定右栏宽度, 左栏内容先出现同时自适应宽度的布局
- 将 SQL Server 实例设置为自动启动(SQL Server 配置管理器)
- Linux批量杀进程
- java笔记之WebProject(一)上传文件
- linux 网络设置 命令
- 获取字符串的长度!
- 《数据结构和Java集合框架第三版》读书笔记(三)回溯算法
- I2S总线
- C++求最小公倍数