- From: Derek Stevenson <derek@eecs.com>
- Date: Sun, 6 Dec 1998 12:51:13 -0500 (EST)
- To: www-dom@w3.org
Hi folks,
I'm attempting to use the appendChild method of the DOMDocument object
(in MSXML 2.0)in order to replicate the various children nodes from one
parsed
document to another, and I'm attempting to do the following;
newXML.appendchild oldXML.childnode(0).clonenode(True)
newXML.appendchild oldXML.childnode(1).clonenode(True)
newXML.appendchild oldXML.childnode(2).clonenode(True)
The purpose is to copy over the first two tags (i.e. the <?xml ...> and
<!DOCTYPE...> directives). However, on the second appendchild method it
balks and tells me the method failed. Based on the documentation, I
know a DOMDocument object can only have a single child Element, so in
those terms I can understand why the appendchild method would fail;
however, how are you supposed to add these first two elements to a new
document object?
Thanks for the help,
Derek Stevenson
p.s. I was referred to this mailing list from some folks at the XML
newsgroup at Microsoft, and said there was a way to subscribe to the XML
discussion list at the W3C. How do I do this, or is there info on your
website?
From - Wed Dec 09 09:36:03 1998
X-POP3-Rcpt: lehors@lanalana
Return-Path: <www-dom-request@w3.org>
Received: from sophia.inria.fr by lanalana.inria.fr (8.8.8/8.8.5) with ESMTP id AAA18957 for <lehors@lanalana.inria.fr>; Mon, 7 Dec 1998 00:02:45 +0100
Received: from www10.w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id AAA21407 for <lehors@sophia.inria.fr>; Mon, 7 Dec 1998 00:02:39 +0100 (MET)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
by www10.w3.org (8.9.1/8.9.1) with ESMTP id SAA18990
for <lehors@w3.org>; Sun, 6 Dec 1998 18:02:37 -0500 (EST)
Received: by www19.w3.org (8.9.0/8.9.0) id SAA27041
for lehors@w3.org; Sun, 6 Dec 1998 18:02:37 -0500 (EST)
Date: Sun, 6 Dec 1998 18:02:37 -0500 (EST)
X-Envelope-From: www-dom-request@www10.w3.org Sun Dec 6 18:02:36 1998
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA27020
for <www-dom@www19.w3.org>; Sun, 6 Dec 1998 18:02:32 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by www10.w3.org (8.9.1/8.9.1) with SMTP id SAA18971
for <www-dom@w3.org>; Sun, 6 Dec 1998 18:01:39 -0500 (EST)
Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA22494; Sun, 6 Dec 1998 15:00:15 -0800
Received: from shorter.eng.sun.com (shorter.Eng.Sun.COM [129.144.250.35])
by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA12846;
Sun, 6 Dec 1998 15:00:14 -0800
Received: from eng.sun.com by shorter.eng.sun.com (SMI-8.6/SMI-SVR4)
id PAA09569; Sun, 6 Dec 1998 15:00:01 -0800
Message-ID: <366B0B64.AA3ACB09@eng.sun.com>
Old-Date: Sun, 06 Dec 1998 14:55:32 -0800
From: David Brownell <db@Eng.Sun.COM>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen McConnell <mcconnell@osm.net>
CC: f.cameron@ulst.ac.uk, www-dom@w3.org
References: <000501be1e05$5c5e5b70$8efca8c0@brian>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Diagnostic: Not on the accept list
Subject: [Moderator Action] Re: Using the DOM with Java
X-Diagnostic: Mail coming from a daemon, ignored
X-Envelope-To: www-dom
X-Mozilla-Status: 8001
Stephen McConnell wrote:
>
> Fiona Cameron wrote:
> > Can anyone tell me whether the DOM/Java is ready
> > for this yet - I can't see anything in the jdk1.2 documentation about
> > the DOM, but maybe I've misunderstood something?
>
> Fiona:
>
> Sun's XML library is not included in the JDK1.2 release, however you can
> download the XML extensions from the following URL:
>
> http://developer.java.sun.com/developer/earlyAccess/xml/index.html
>
> This download provides a bunch of XML related stuff, including an
> implementation of DOM - however it is an non-conformant release at this
> stage. According to Sun's documentation they are in the process of bring
> this to up-to-date with the DOM recommendation.
It was actually updated the day before Stephen's post, so at most
only minor conformance problems should remain. Drop a line if you
find any (to the address noted in the release).
- Dave
From - Wed Dec 09 09:39:52 1998
X-POP3-Rcpt: lehors@lanalana
Return-Path: <www-dom-request@w3.org>
Received: from sophia.inria.fr by lanalana.inria.fr (8.8.8/8.8.5) with ESMTP id CAA28982 for <lehors@lanalana.inria.fr>; Wed, 9 Dec 1998 02:39:45 +0100
Received: from www10.w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id CAA25713 for <lehors@sophia.inria.fr>; Wed, 9 Dec 1998 02:38:58 +0100 (MET)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
by www10.w3.org (8.9.1/8.9.1) with ESMTP id UAA18618
for <lehors@w3.org>; Tue, 8 Dec 1998 20:37:59 -0500 (EST)
Received: by www19.w3.org (8.9.0/8.9.0) id UAA12850
for lehors@w3.org; Tue, 8 Dec 1998 20:37:59 -0500 (EST)
Date: Tue, 8 Dec 1998 20:37:59 -0500 (EST)
X-Envelope-From: www-dom-request@www10.w3.org Tue Dec 8 20:37:02 1998
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA12786
for <www-dom@www19.w3.org>; Tue, 8 Dec 1998 20:36:05 -0500 (EST)
Received: from localhost ([132.248.237.29])
by www10.w3.org (8.9.1/8.9.1) with ESMTP id UAA18600
for <www-dom@w3.org>; Tue, 8 Dec 1998 20:35:51 -0500 (EST)
Received: (from fm@localhost)
by localhost (8.8.8/8.8.8) id SAA00506;
Tue, 15 Sep 1998 18:45:43 -0500 (CDT)
Message-Id: <199809152345.SAA00506@localhost>
To: www-dom@w3.org
Cc: fm@linux.audiotel.com.mx
Old-Date: Tue, 15 Sep 98 18:44:35 -0500
From: Fabio Montoya <fm@w3.org>
received: by Apple.Mailer (2.82.RR)
X-Diagnostic: Not on the accept list
Subject: [Moderator Action] PR-DOM-Level-1-19980818
X-Diagnostic: Mail coming from a daemon, ignored
X-Envelope-To: www-dom
X-Mozilla-Status: 8001
This are my comments as a non-member to the PR-DOM-Level1-19980818:
"Document Object Model (DOM) Level 1 Specification Version 1.0 W3C
Proposed Recommendation 18 August, 1998"
This comments are done after three implementations of the DOM in
Objective-C, using the YellowBox/OpenStep Apple/NeXT frameworks.
NodeList and NamedNodeMap. The "liveliness" of this interfaces
creates problems when at least one out of two threads of execution
modifies the NodeList or NamedNodeMap and other[s] iterate through
the contents. The clean object-oriented way to preserve this
"liveliness" is to provide Iterators or Enumerators to the contents
which take a "snapshot" of the contents of the collection object.
I propose to define this Enumerator/Iterator interface in DOM 1.0 to
provide forward-comaptibility when thread-safety arrives to the DOM
recommendation.
Node.
=====
The "Node" interface makes the concrete classes of the
implementation respond to many message not related to the nature of
the class, Like "accessor" methods to non-required instance-variables
example: attributes [accessory method] returns null for all subtypes
of Node except Element [seems like is an attribute of Element not
Node].
Likewise nodeValue is used for Attribute, Text, CDATASection and
processing Instruction but not the others.
Similar is nodeName, but when not used this responds to predefined
constants instead of null. This behavior is inconsistent, because
there are some nodes which will never respond with the predefined
constant. I propose to respond with null when there is no name
associated. If required, could be defined a new className method
which could respond with the interface name of the node, making this
behavior consistent.
NodeList
=======
NodeList should have the following attributes and methods removed
from Node: firstChild, lastChild, insertBefore, replaceChild,
removeChild, appendChild, hasChildNodes. Also could have the
following methods previousSiblingOf(Node), nextSiblingOf(Node)
similar to the existent attributes in Node.
Element
=======
remove methods:
wstring getAttribute(in wstring name);
void setAttribute(in wstring name,
in wstring value)
raises(DOMException);
void removeAttribute(in wstring name)
raises(DOMException);
Attribute getAttributeNode(in wstring name);
Attribute setAttributeNode(in Attribute newAttr)
raises(DOMException);
Attribute removeAttributeNode(in Attribute oldAttr)
raises(DOMException);
Use the appropriate in NamedNodeMap.
NOMENCLATURE
===============
In the sake of consistency an a clean object-oriented design,
Node.nodeName, Element.tagName and other node names should all be
renamed simply "name". Prefixing an instance variable with the
type/class as in nodeName is a wrong approach to O-O.
INSTANTIATION
=============
The creation of node objects requires to comply the DTD semantics,
so in order to make this cleaner, the creational methods in Document
should be moved to DocumentType which should hold the rules of
creation of node elements.
REQUIRES PRECISION
==================
The specification for method Text.splitText(in unsigned long
offset), requires an example to clarify what happens when a Text with
3 characters is divided at offset 1?. Who knows thte answer, the
spec does not tell.
What is the rule to return a predefined constant when calling to
Node.nodeName?. What happens when a node with a name instance
variable does not have an associated name value? Should respond null
or should respond the predefined constant?
MISSING XML constructs
====================
Where is thte interface to access the XMLDecl [<?xml version="1.0"
encoding="UTF-8"?>] ? May I use a regular ProcessingInstruction?
Fabio Montoya Garcia
fm@tirania.linux.org.mx
fm@linux.audiotel.com.mx
The Open Component Society
From - Wed Dec 09 09:39:47 1998
X-POP3-Rcpt: lehors@lanalana
Return-Path: <www-dom-request@w3.org>
Received: from sophia.inria.fr by lanalana.inria.fr (8.8.8/8.8.5) with ESMTP id CAA28970 for <lehors@lanalana.inria.fr>; Wed, 9 Dec 1998 02:35:24 +0100
Received: from www10.w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id CAA25643 for <lehors@sophia.inria.fr>; Wed, 9 Dec 1998 02:35:16 +0100 (MET)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
by www10.w3.org (8.9.1/8.9.1) with ESMTP id UAA18595
for <lehors@w3.org>; Tue, 8 Dec 1998 20:35:09 -0500 (EST)
Received: by www19.w3.org (8.9.0/8.9.0) id UAA12779
for lehors@w3.org; Tue, 8 Dec 1998 20:35:09 -0500 (EST)
Date: Tue, 8 Dec 1998 20:35:09 -0500 (EST)
X-Envelope-From: www-dom-request@www10.w3.org Tue Dec 8 20:35:07 1998
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA12758
for <www-dom@www19.w3.org>; Tue, 8 Dec 1998 20:35:07 -0500 (EST)
Received: from localhost ([132.248.237.29])
by www10.w3.org (8.9.1/8.9.1) with ESMTP id UAA18592
for <www-dom@w3.org>; Tue, 8 Dec 1998 20:34:51 -0500 (EST)
Received: (from fm@localhost)
by localhost (8.8.8/8.8.8) id RAA00485
for www-dom@w3.org; Tue, 15 Sep 1998 17:11:41 -0500 (CDT)
Message-Id: <199809152211.RAA00485@localhost>
To: www-dom@w3.org
Old-Date: Tue, 15 Sep 98 17:10:37 -0500
From: Fabio Montoya <fm@w3.org>
received: by Apple.Mailer (2.82)
X-Diagnostic: Not on the accept list
Subject: [Moderator Action] PR-DOM-Level1-19980818
X-Diagnostic: Mail coming from a daemon, ignored
X-Envelope-To: www-dom
X-Mozilla-Status: 8001
This are my comments as a non-member to the PR-DOM-Level1-19980818:
"Document Object Model (DOM) Level 1 Specification Version 1.0 W3C
Proposed Recommendation 18 August, 1998"
This comments are done after three implementations of the DOM in
Objective-C, using the YellowBox/OpenStep Apple/NeXT frameworks.
NodeList and NamedNodeMap. The "liveliness" of this interfaces
creates problems when at least one out of two threads of execution
modifies the NodeList or NamedNodeMap and other[s] iterate through
the contents. The clean object-oriented way to preserve this
"liveliness" is to provide Iterators or Enumerators to the contents
which take a "snapshot" of the contents of the collection object.
I propose to define this Enumerator/Iterator interface in DOM 1.0 to
provide forward-comaptibility when thread-safety arrives to the DOM
recommendation.
Node.
=====
The "Node" interface makes the concrete classes of the
implementation respond to many message not related to the nature of
the class, Like "accessor" methods to non-required instance-variables
example: attributes [accessory method] returns null for all subtypes
of Node except Element [seems like is an attribute of Element not
Node].
Likewise nodeValue is used for Attribute, Text, CDATASection and
processing Instruction but not the others.
Similar is nodeName, but when not used this responds to predefined
constants instead of null.
childNodes, firstChild, lastChild.- Should not be in Node, should
appear when the node can contain others.
previousSibling,nextSibling.- In all my implementations does not
make sense to make a node know about siblings, only about a parent.
This interfaces could have similars previousSiblingOf and
nextSiblingOf in the parent nodes.
Fabio Montoya Garcia
fm@tirania.linux.org.mx
fm@linux.audiotel.com.mx
The Open Component Society
Received on Monday, 14 December 1998 08:38:42 UTC