But i have tried used the jaxp and jdom, i feel the sturcutre of dom interface can actually be simplified, Because the Jdom can handle xmo element atrributes, text, name.. as well. My question is, why the node and nodelist interface is needed there?
Then do you mean that, the purpose of Node and Nodelist is to provide a concise definition for XML, so any language like C++, Perl can manipulate, if only for Java, is Jdom enough?
another problem, i noticed that Sun provide reference implementation for jaxp, and it is included in jdk1.4. Now if I want to replace that version with a better alternative, like xerces, what is the easiest way?
to wangwenyou(王文友):I think you are a experts in OOP and XML as well, might i know where you are and what are you doing? As I am targeting to become an expert in this field, I would like to learn from you.Thank you for your proper and consice answers.
wangwenyou(王文友): W3C的DOM规范个人觉得更为严谨复杂－－它要考虑多种语言共用同一接口；而JDOM则不同，它只为Java程序员量身定做 Could you please give an example where DOM's def can work while JDOM's can't work for a language like C++? (Not familiar with JDOM, also want to learn from you) Thanks.
Actually, when the size of the xml document exceed certain limit, say 500k, it's very slow to parse either using Dom to Jdom. It's similar to query a database stored in text format.W3c are developing some kind of query language call x-query. Also now Sql server, DB2 and Oracle all support xml retrieval and storeage in their database. Native xml database exist as well, like tamino from software AG.I do not see the application/use of Dom/Jdom, except for parsing some configuration files or property files. As for real applications, people are looking for XSLT, x-query.Am I right?
to wangwenyou(王文友): I agree with you that XML should not be used for database storage, as its extra tags would increase the size of a database. It seems that xml only has its advantage when using as exchange document between different Enterprise/Applicaitons.But: "我可以把其中一些数据表移到Mysql、Sybase甚至Xml中，实现分流减负。"
Are you sure to export your RDBMS into xml format? If without any XML database and query language, how can you deal with 100M xml file?
Thank you wangwenyou(王文友) , you are excellent.Would like to discuss your further in the future.
wangwenyou:除非有人为它的接口写一个C++或其它语言的实现 Sounds like the only thing jdom does not have is some impls in other languages. if people are not so lazy and give some impls, jdom should be able to replace dom?but what's the point of w3c to define such an ugly dom while some simpler interfaces like jdom can be defined? Are they stupid or crazy?I'm guessing that either jdom is not flexible enough(like, it cannot solve some specific situation), or jdom has something dependent on Java language, which, I know it's at least using Java Collection framework. But from what you said, even if jdom defines some language neutral inerface, it should still be simpler than dom.
Element固然是一个Node，但Attr、 Document和Text等都属于Node。
至于NodeList，它是一个平面结构存储的容器，与Node的树状结构相异。
JDOM中把Element、Attribute和Document分离开了，作为不同的事物。
而DOM中则把三者都作为有自己特性的同一事物：Node。
各有各的好处，W3C的DOM规范个人觉得更为严谨复杂－－它要考虑多种语言共用同一接口；而JDOM则不同，它只为Java程序员量身定做，所以，它不必考虑那么多问题，它的接口简单，使用起来方便。
请看下面的示例：
Attr attr;
Element element;
Document document;
因为它们都继承自Node，所以都可以作为Node置入一个NodeList中
这是Node存在的必要性
NodeList中的Node可以分别取出，造型为相应的类型。
if only for Java, is Jdom enough?
Now if I want to replace that version with a better alternative, like xerces, what is the easiest way?
第二个问题，不必担心，JAXP很规范，你想使用Xerces和Crimson的实现都可以，随时可以简单的切换。
W3C的DOM规范个人觉得更为严谨复杂－－它要考虑多种语言共用同一接口；而JDOM则不同，它只为Java程序员量身定做
Could you please give an example where DOM's def can work while JDOM's can't work for a language like C++?
(Not familiar with JDOM, also want to learn from you)
Thanks.
呵呵，谢谢谬赞，不敢当
我在北京，程序员
至于兄弟，以程序人生作为自己事业的程序员，我们都是兄弟：）To ajoo
唉，ajoo兄，你给我出了个难题，等我引经据典，看看资料再给你答复好吗：P
呵呵，不过我喜欢这样的问题，正好可以深入学习一下
JDOM是完全独立的一套接口，它并不遵从DOM的规范，所以，DOM适用于其它语言，而它只能用于Java，除非有人为它的接口写一个C++或其它语言的实现：）
在JDOM中，没有NodeList这种事物，而代之以JDK Collenction中的List。
就拿简单的取节点值操作来说吧，例如XML中有一个这样的节点
<node>value</node>
照我们通常的习惯，很自然的取值是这样的：curNode.getNodeValue("node")
但在DOM中，这样是取不到值的，你必须写一大堆代码，你首先要判断它是不是ELEMENT_NODE，然后getFirstChild()，然后检查是否null，是不是TEXT_NODE，最顺利的情况，取值的语句为curNode.getFirstChild().getNodeValue()。
而JDOM这方面就很符合Java程序员的习惯：curNode.getChildText("node")，很简单，很直接。
虽然JDOM功能上有一定的欠缺，也许没有DOM那样强大，但如果这些功能对我们的应用足够的话，我倾向于使用JDOM去写通俗自然易维护的代码。
It's similar to query a database stored in text format.W3c are developing some kind of query language call x-query. Also now Sql server, DB2 and Oracle all support xml retrieval and storeage in their database. Native xml database exist as well, like tamino from software AG.I do not see the application/use of Dom/Jdom, except for parsing some configuration files or property files. As for real applications, people are looking for XSLT, x-query.Am I right?
Apache也开发了一个类似的项目：xindice。
不过因为文件IO本身的局限性和DOM的先天缺陷，使用Xml作为最终数据存储载体的，真是少之有少。
但是，我的应用中使用了Xml，在我的应用中，Xml可以作为配置文件，也可以充当数据表的角色，还可以随时通过配置文件的简单修改，在数据库存储和Xml存储之间切换。
拿最简单的例子来说吧，我要开发一个应用，首先，数据表都在一个SqlServer的数据库中，当用户访问频繁导致数据库服务器不堪重负时，我可以把其中一些数据表移到Mysql、Sybase甚至Xml中，实现分流减负。
Xml的出现，给我们的应用带来了很大的灵活性。可以说，Java的出现给我们的应用带来平台无关性；而Xml则给我的应用带来了数据存储载体的无关性。
I agree with you that XML should not be used for database storage, as its extra tags would increase the size of a database. It seems that xml only has its advantage when using as exchange document between different Enterprise/Applicaitons.But: "我可以把其中一些数据表移到Mysql、Sybase甚至Xml中，实现分流减负。"
Are you sure to export your RDBMS into xml format? If without any XML database and query language, how can you deal with 100M xml file?
这方面还是得根据具体情况进行相应的处理，数据量太大的当然不能用XML存储，最实用的功能是应用发布试用版时，我可以给客户XML版本。
至于查询，简单的查询用XQL即可。
我的最终目标是数据表、XML、甚至邮件、JNDI的LDAP服务使用同一接口访问。
Sounds like the only thing jdom does not have is some impls in other languages. if people are not so lazy and give some impls, jdom should be able to replace dom?but what's the point of w3c to define such an ugly dom while some simpler interfaces like jdom can be defined? Are they stupid or crazy?I'm guessing that either jdom is not flexible enough(like, it cannot solve some specific situation), or jdom has something dependent on Java language, which, I know it's at least using Java Collection framework. But from what you said, even if jdom defines some language neutral inerface, it should still be simpler than dom.
JDOM的缺点在于更新慢，不能很快适应XML标准的变化，比如Schema的支持，它就比较薄弱，有待于继续发展。
就拿我举的例子来说吧
<node>value</node>
有可能会是
<node><!-- Comment -->value</node>
DOM的处理方式是充分考虑内部可能出现的注释或其它类型节点，在此，NodeValue确实不能完全表现node的内部。
JDOM的处理方式是通过getChildText取到value，其实，从大部分程序员的习惯和需求上来说，我们是不关心<!-- Comment -->的，如果需要操作Comment，JDOM也提供了getMixContent。
处理方式不一样罢了，不能简单的判定孰优孰劣。
JDOM的缺点在于更新慢，不能很快适应XML标准的变化，比如Schema的支持，它就比较薄弱，有待于继续发展。
就拿我举的例子来说吧
<node>value</node>
有可能会是
<node><!-- Comment -->value</node>
DOM的处理方式是充分考虑内部可能出现的注释或其它类型节点，在此，NodeValue确实不能完全表现node的内部。
JDOM的处理方式是通过getChildText取到value，其实，从大部分程序员的习惯和需求上来说，我们是不关心<!-- Comment -->的，如果需要操作Comment，JDOM也提供了getMixContent。
处理方式不一样罢了，不能简单的判定孰优孰劣。
JDOM的缺点在于更新慢，不能很快适应XML标准的变化，比如Schema的支持，它就比较薄弱，有待于继续发展。
就拿我举的例子来说吧
<node>value</node>
有可能会是
<node><!-- Comment -->value</node>
DOM的处理方式是充分考虑内部可能出现的注释或其它类型节点，在此，NodeValue确实不能完全表现node的内部。
JDOM的处理方式是通过getChildText取到value，其实，从大部分程序员的习惯和需求上来说，我们是不关心<!-- Comment -->的，如果需要操作Comment，JDOM也提供了getMixContent。
处理方式不一样罢了，不能简单的判定孰优孰劣。