@hello cvpc
是的，从一个技术的规定上来说，这样说应该没错。
不过我想，XML更重要的是数据的分离和定义，XSL则不一定要生成XHTML，它也可以生成PDF，WORD-DOC，或者任何你喜欢的其他所需格式。

你指出了很重要的一点，我们这里一直讨论的XML-XSL解析，是特指XML被浏览器端通过XSL解析生成为XHTML；如果这个网站面向的不是使用IE/Firefox/Safari的用户，而是一个手持终端，是一个Pdf阅读器，是GoogleDocs，是智能电视机或者智能窗帘开关——那是另外的话题了。

在现在，对手机或者搜索引擎的兼容，输出不同的格式也是勉力为之的办法吧。

引用:

原帖由 Aether 于 2007-4-13 15:02 发表
@1356803
XML+XSL解析以后是XHTML代码，应该不包括CSS，CSS应该是独立的，JS也是，现在有很好的触发器来绑定事件，各层之间应该已经可以做到非常好的分离和良构。

至于诸多好处，我认为，想是永远想不明白了 ...

我也做过这个，我所指的是xml（数据）+xsl（修饰壳）出来的页面是要xsl里面的xhtml定结构，通过css来布局修饰，而现有的页面就是数据+xhtml（结构）+css（布局修饰），这样不是少了一个xsl加壳的过程么？为什么还要多此一举，如果说是为了不同的浏览设备，那么用js判断浏览设备然后调不同的css去控制他的显示效果，不是一样的么？我现在没有明白，xsl去转换xml，到底好在哪里？而且，这样说吧，前台和后台同时进行xsl和xml的编写，那么前期的结构名称统一是不能有任何疏漏的，否则对不上，这个不是很大程度上存在命名隐患吗？

@1356803  ^^
持续讨论，说我的观点。
首先，XHTML作为结构是固定的，不够灵活，例如同一个结构你需要多次重复书写，而XSL就可以通过匹配一次性完成或这组合，并且可以对不同的数据提供不同的微观结构片段，这一点我已经多次重复了^^；
其次，你提到用js调css，但是如果是某个用户自己用VB写的桌面程序？或者是搜索引擎的爬虫？或者是一个pdf阅读器？或者只是一台电视机呢？
其三，隐患通过文档和合作避免，我想这是基本技能和前提：）

这些问题中，我认为对目前浏览器市场中，最有意义的，还是第一点。

还有一些有趣的东西，比如你要显示一个blogpost上有多少条留言，在传统的XHTML中你需要程序去输出一个数值，但是在XSL中，你只需要数一下（COUNT(NodeName)），就可以了。Simple，Clean，这只是冰山一角，对不对？：）

引用:

原帖由 Aether 于 2007-4-13 16:58 发表
@1356803  ^^
持续讨论，说我的观点。
首先，XHTML作为结构是固定的，不够灵活，例如同一个结构你需要多次重复书写，而XSL就可以通过匹配一次性完成或这组合，并且可以对不同的数据提供不同的微观结构片段，这 ...

我只写了一点，至于你说的第一个，我没见到例子，是没那么容易死心滴，嘿嘿，发个例子吧，至于说文档合作避免出错，我对现在的公司合作能力持不乐观态度，呵呵，毕竟领导让改，俺也只好听他的了，写的不多，希望能被你拖进xml的大门

多学一个东西不是坏事。。

愿意学的就学撒。

别人说不好不学那也没办法。别让别人思想妨碍自己就好了。

我是愿意学，但是身边很多同事不看好这玩意，说微软自己出的自己都不用，我无力反击啊，加上自己应用的少，自然有了误解，所以才需要你们走在前面的人来拨乱指正，引导光明的大道啊

@1356803  
我正好在另外一个帖子里面提到，微软最新推出的Web平台，全套战线，WPF，就是以XAML为核心连接表现层和程序的，而XAML，就是微软自定义产品规范的XML。Adobe的ColdFusion，我印象里也是以自定义XML为主线贯穿程序和表现层。这个思路、想法和应用和我们使用自定义XML连接后台程序到XHTML是完全一致的。你可以去随意翻翻，不用深究就应该可以了解到。

所以趋势和方向，我自己是没有疑惑的，只是觉得自己跑得太慢。

至于XSL的灵活性，我觉得这个一言难尽，但是说穿了又不值一提。
例如，你用程序输出一个XML的文章列表，包含完整的标题内容时间作者等等，那么这个列表的XML文件前台也可以用，后台也可以用，只是调用不同的XSL去格式化而已，格式化后的XHTML去取用不同的CSS样式和Javascript行为层逻辑。对于程序来说，意味着复用性很高，他只需要输出一次，不同的业务需求则通过不同的XSL自行去筛取自己需要的数据。
以此类推。我不知道这个陈述是否清楚呢？

概括的说，xml是一次获得数据，多种表现形式
他是一种标准，数据通讯的标准
如果一些数据只在一个地方显示、处理。那么，弄成xml是多此一举。。。。

关于这个forest53老兄早已做了测试
http://www.forest53.com/test/lernplus/index.xml
http://www.forest53.com/test/lernplus/xsl/home.xsl

顺便，我使用DW8已经可以建立XSL可视化操作XML
http://dw8.cn/forum/upload/2005_10_18/testxml/mysite.xml

DW8新功能 之 建立XSLT页可视化操作XML数据
http://www.cnbruce.com/blog/showlog.asp?cat_id=34&log_id=739
http://www.cnbruce.com/blog/showlog.asp?cat_id=34&log_id=740

======================

还是那句话，目前对搜索引擎不友好。面对XML页，GG还好，百度简直就是"白痴"(原谅我使用这个词，确实效果不行)

http://www.google.cn/search?sour ... txml%2fmysite%2exml
GG就能搜索并显示出XML页面的内容

http://www.baidu.com/s?wd=testxml%2Fmysite.xml&cl=3
在看百度呢，只有含有该关键字文本的普通页面

目前的XHTML标准真的是过渡，同样也是XML结构，这对于我们页面设计来说，很不错。

如果你的页面主要是用来数据交互的，那么XML的页是最适合的

有的时候应该看项目的需求，环境决定一切，此前的WML就是一例

很同意z3333426 所言

[ 本帖最后由 cnbruce 于 2007-4-13 20:34 编辑 ]

搞技术的都喜欢讨论技术本身，却不知你再先进的技术都是靠市场驱动。

引用:

原帖由 Aether 于 2007-4-13 15:02 发表
@1356803
XML+XSL解析以后是XHTML代码，应该不包括CSS，CSS应该是独立的，JS也是，现在有很好的触发器来绑定事件，各层之间应该已经可以做到非常好的分离和良构。

至于诸多好处，我认为，想是永远想不明白了 ...

我以前从来没仔细了解过，见你们争论了这么多，自己根据cnbruce 提供的http://dw8.cn/forum/upload/2005_10_18/testxml/mysite.xml写了另外一个例子，马上就了解Aether所想表达的一些思想，1356803，我想你应该动手写一下，就马上可以了解Aether的意思了！

[ 本帖最后由 leaon 于 2007-4-14 01:38 编辑 ]

看了前12楼的帖子之后，没耐心继续看下去了。
估计在这个帖子里发言个兄弟都是单纯关注Web标准，甚少关注程序部分的。

Ruby on Rails最近流行一种思想，估计也是未来的趋势，就是REST。这里不多解释，有兴趣的可以找相关文章看看。

大概的意思就是，我们做网站仍然是XHTML+CSS，这是主流，XML只是用来传递数据的。网站程序会自动根据你的浏览器类型选择调用XML或传统的XHTML。

当然，写起来非常非常的简单。

如果你做的网页是为了主流，有商业目的，那我建议还是基于XHTML的web标准吧。XML+XSLT作为玩票性质完全可以。

大家可以翻番以前的帖子。貌似1年之前，这儿绝对有人已经讨论过这问题了。

[ 本帖最后由 sexboy024 于 2007-4-14 09:28 编辑 ]

学习来了

@5tudio,@1356803
就此问题我昨晚上亦请教了livid，看他的观点如何，我认为他的答案和你们的想法是非常共同的。
那就是这东西的好坏，大量的普及，并不是说技术人员们自己就可以完全一力推行的，
是否能真正提高效率，减低成本，得到实实在在的好处，引导商业化的力量来帮助推行，才是普及的道路。

我觉得这个说法是对的，我也相信，XML的架构一定会带来这样的好处，这包括我自己实验收获的心得。

@sexboy
REST is another thing.

小声的说下下啊~
XML+XSL+CSS+JS是服务器压力太大时的解决方案，而且是已经在客户端预加载了XSL+CSS+JS的，即只从服务器读取XML数据，再在客户端用XSL+CSS+JS解析成人类可以看的玩意儿~从而达到减轻服务器压力的目的~
如果，只是把页面搞成XML+XSL+CSS+JS，而没有在客户端预加载的部分，那就是在增加服务器压力了，服务器要分别生成这四部分的文件，同时客户端要从服务器端分别请求这四部分的文件~同志们啊，这就是服务器和带宽啊，这都是钱啊~钱不是这么用来浪费的啊~
当然，不是说这样做不可以，只是你有办法在用户的电脑上预先加载好除XML以为部分的文件么？（提示：可以以软件或插件的方式预先加载）
学以致用，小声给大伙提醒一下，学了最好要知道用在哪里最合适哦~

@s5s5  
XSL，CSS，JS通常情况下都是静态文件，浏览器是会在本地自行缓存的，包括没有变化的XML文件（例如首页，或者某个单独的post页面，等）。
当然，第一次访问的时候是会从服务器读取。你可以使用Charles或者Firebug来观察到哪些元素被load from cache。

本来，页面上相同的元素，例如页头页尾的数据部分，例如本月热门浏览文章等内容，本来也应该可以分拆为独立的XML放在客户端缓存，但是可惜的是眼下浏览器都不支持xsl:include，所以我现在的方案只好在服务端组合成为完整的页面XML之后输出。

这些页面可以在服务器上做应用程序级缓存拟静态（我想.net php java都可以很好地做到这一点），有效地解决压力问题；到了应用程序这一级别，其实和其他眼下正在使用的大部分解决方案已经没有区别了。

[ 本帖最后由 Aether 于 2007-4-14 18:29 编辑 ]

xml是王者，浏览器支持的问题很麻烦，个人敢觉xml已经可以学习了，毕竟xml的功能实在强大。

xsl应用目前还是受到方方面面的限制，算是老生常谈了，
抽空还是常关注一下新的HTML工作组的进展吧：
http://www.chinaw3c.org/press/20070307.htm

别忘了还要通过XSL表现！
对于XML是在数据代码方面规范了不少
但XSL的表现只能说要求比现在所用的技术还高

引用:

原帖由 zbm2001z 于 2007-4-15 22:58 发表
xsl应用目前还是受到方方面面的限制，算是老生常谈了，
抽空还是常关注一下新的HTML工作组的进展吧：
http://www.chinaw3c.org/press/20070307.htm

认同.

顺便纠正楼主几个错误概念:

引用:

"...[本月话题] 对于web标准，是否应该更进一步

不是更进一步而是把web标准概念扭曲了。

引用:

"...然而到今天，我收到的简历大部分依然是言必称DIV+CSS的初学者们。".

DIV+CSS不是网页标准,但却是网页的一个技术标准.你把DIV+CSS定位为初学者，那高学者是什么？

引用:

"..就连网页标准本身，也是在阿捷等一批先驱的引领下，直到去年开始才在国内得到缓慢普及"

网页标准是一个多维的慢慢渗透、逐渐普及的过成,不是某一个人引领普及的。

另外，XML+XSL...的确是很优秀的工具，我也在学。但XHTML本身也在发展，XHTML1.0...XHTML2.0......

@iuui  
1、论坛中讨论概念是痛苦的，因为一个字的偏差就可以引来大篇的抨击，双方越说越远，你觉得我扭曲了，那就算是吧^^||| 我原来的标题是《做网页标准的工作者们，我们应该更进一步了》，后来版主改成了更合适讨论的话题，我觉得这样也是挺好的，进退飞立，应该没有太大的关系吧。
2、我认为非初学者至少对整个网页标准及相关技术的熟悉和了解，技术就不说了，这以外，至少应该知道，表现，结构，行为层，语义，易用性，效率，分工与合作……等等，我一时也列举不完；在这之上，最好有自己独立的见解。归总而言，我认为技术先行，但重在理解。
3、同第一项，请注意我的用词，“等”，“引领”，不是他一个人做。好了，我们不用在这里讨论这些东西吧，呵呵。

@zbm2001z  
传说中的HTML5或者XHTML2，我认为这都只是XML的表现层，是XML经过XSL解析以后的其中一种表现方式，你觉得呢？

题外话，微软的人认为W3C从工作方式到效率，到产品都是上个世纪的东西，我一时语塞，想反驳，也说不出口：（
总体看来，他们的工作进度确实太慢了，不过我自认就连这样我也无能为力，没有能力帮助他们，只好帮他们干着急吧。或许，我们这样动手做，就是最好的支持和推进方式。

------------
我看到blankzheng的新作品马上就会出来了，希望能够尽快给大家更多的范例和参考。
大家一起来玩吧：）

[ 本帖最后由 Aether 于 2007-4-16 13:54 编辑 ]

引用:

原帖由 leaon 于 2007-4-14 01:33 发表


我以前从来没仔细了解过，见你们争论了这么多，自己根据cnbruce 提供的http://dw8.cn/forum/upload/2005_10_18/testxml/mysite.xml写了另外一个例子，马上就了解Aether所想表达的一些思想，1356803，我想你 ...

我做过那个例子http://www.beyond-live.com/xml/a.xml,我想问，做一个累死雅虎，新浪，奇虎的新闻首页面，这xml+xsl的开发速度和难度会比xhtml快且小吗？而且我现在脑子里对做这样的网站，xml+xsl该如何下手，没有一个概念，再者说xml的重复利用xsl模板解析，在这样的网站里，如何重复？什么地方重复？这些，是我想要了解的，我所阐述的意思，就是对于商业网站这种布局来说，怎么样真正的下手去改造它，而不是xml只能做类似于blog这样简单布局的东西，我停下学xml，也是在这个问题上困惑，怎么样把手里的知识化作处理商业作品的能力，才是我想要的答案

插一句，这样写，将来差错ms很麻烦啊。。。firebug的dom解析失灵。。。得满页面找代码。。。大海捞针啊

@1356803
^^ 我知道你的疑惑是正确的，商业化的驱动也是必要的。
但是我只能说，就我自己对XSL的理解，你的这些疑问都不成为问题，但是我觉得，我怎么说也没有用，你一直疑惑下去也是没有用的。唯一的解决办法，我觉得只可能是动手做一个，这个先河，可以由你来开，大家都可以从你的示例中得到启发，得到收获。

至于firebug，我的想法和一直提到的一样，我觉得是因为没有切实用起来，真正发挥它的力量，未能引人重视，是我们自己推动不力。我已经去信询问此事，你也可以发信问问，关注的人多些，才可能得到一些答复和重视。

最后说到实际动手，我的做法可能是：
可复用的元素，视调用的不同频率和类别放在多个xsl中等待include，比如头尾，列表，Article，Pagebar等等。
在页面级的xsl视情况调用这些子xsl，把独立的不重复的写在当前xsl，然后只需要apply-templates就可以了。
动态的XML仅输出变化的数据，静态的XML在服务端和动态数据通过程序include在一起整体输出。

但是，正如我所说，这些怎么说都太简陋，你不必等待任何人给你送到眼前，或者在困惑中迟迟不决，只需要去做就可以了，做不出来的地方就去Google，一般来说，换十来个关键词，翻上五十页必有答案——基本的技术是绝不成问题的，实在不行，可在这里发帖，找人肉搜索代劳（这一段好像我在楼顶写过^^||||）。

我们大家都是开路者，奠基人，我们自己开创我们想要的东西，既然觉得XML和XSL好，那就做，至于怎么做，是另外的事情。一起走吧。

[ 本帖最后由 Aether 于 2007-4-16 15:09 编辑 ]

楼主，我也是刚学不久xsl，现在估计都还给书本了，毕竟不常用，思路不对啊，我很怀疑我自己作出的东西是不是xhtml的翻版，就好像刚开始做css+div，每一块一个div+id，根本不知道怎么利用class，我现在就是老虎吃王八，不知道该怎么下手写这玩意，就比如说两个布局差不多但是内容不同的块，一个居左，一个居右，怎么去拆分，是调用同一个xsl还是写两个xsl，这些我都在迷惑中，因为没见过这样的例子，不知道自己想法对不对，有空我试试看吧，我就怕自己学习的xsl最后成了转译自己写的结构名xml的一套壳，而失去了他应该有的有点和好处

怿飞的大作，共赏。
http://www.planabc.net/xml.asp

请大家掏出各自的家伙，开始刨代码^^
我推荐必装的一个插件是ViewSourceChart，可以输出经过渲染以后的最终XHTML代码和染色图。

你的标题应该改成《XSL、XML-在WEB中的应用和实践》

要知道不管XSL、XML再强大也永远替换不了XHTML成为WEB的标准。
XSL仅仅是一个能把XML转换成各种格式的工具（包括HTML），仅此而已。

引用:

原帖由 Aether 于 2007-4-16 12:34 发表
@iuui  
题外话，微软的人认为W3C从工作方式到效率，到产品都是上个世纪的东西，我一时语塞，想反驳，也说不出口：（

总体看来，他们的工作进度确实太慢了，不过我自认就连这样我也无能为力，没有能力帮助他们，只好帮他们干着急吧。或许，我们这样动手做，就是最好的支持和推进方式。

正是由于W3C严谨态度和你所认为的“缓慢”速度进行这标准的制定，你才有机会在这提到“标准”这个话题。

至于微软——谁是主要的WEB标准混乱和无序制造者呢？（当然企业有商业利益驱动也无可厚非，也懒得B4）
去问问大多数WEB标准的先驱吧！

[ 本帖最后由 zbm2001z 于 2007-4-17 09:52 编辑 ]

引用:

原帖由 iuui 于 2007-4-17 00:04 发表
要知道不管XSL、XML再强大也永远替换不了XHTML成为WEB的标准。

引用:

WEB标准不是某一个标准，而是一系列标准的集合。网页主要由三部分组成：结构（Structure）、表现（Presentation）和行为（Behavior）。对应的标准也分三方面：结构化标准语言主要包括XHTML和XML，表现标准语言主要包括CSS，行为标准主要包括对象模型（如W3C DOM）、ECMAScript等。

引用:

微软的人认为W3C从工作方式到效率，到产品都是上个世纪的东西！

可以这样反驳：微软的开发连上个世纪的东西都支持的非常差！
特指VS.Net 2003