Gareth Reakes wrote: > >With xml-parsed DOMDocuments, the document's root element contains > > the xmlns-attribute, if given in the xml-file. In contrary, newly > > created DOMDocuments' root elements never contain the > > xmlns-attribute, although a namespace-argument was given to > > createDocument, but the DOMWriter-serialized output shows the > > xmlns-attribute, as expected. This is inconsistent. > > This is correct behavior. A DOM tree does not need an xmlns attribute > to tell it what namespace an element is in. In fact, namespace attrs > are a parse time thing. They are completely ignored after parse.
Hi Gareth, If this was correct behaviour, I would expect xmlns attrs be removed from the attribute list of the DOMDocument's root element by the parser, when parsing an xml document. But my observation is that all attributes (incl. xmlns) appear there after parsing. Or did I miss setting a property referring to this? > >Even worse: adding the xmlns-attribute manually to the root element > >after creation, the serialized output shows the xmlns-attribute > >twice, which is illegal with respect to the XML specification. > > This is indeed incorrect. Could you provide the xml file and code > that produces this? There's no related xml file, since the described behaviour occurs only with newly created DOMDocuments (see my examples below, CASE 2). A sentence about my context: I'm writing a qt-plugin frontend for viewing and editing DOM trees. I noticed the described behaviour differences between loading (and parsing) an existing xml file and creating a new one, when providing element selection highlightning in the serialized output. [...] > >o elem contains no attributes (e.g. elem->hasAttributes() returns > >false resp. elem->getAttributes() is empty) > >o serialized shows the provided xmlns-attribute > > This is correct behavior. The DOMWriter "fixes" the xmlns on the way > out so you can parse it again and get the same document. But after reparsing, the xmlns attr actually is in the attribute list! > >CASE 2: > > > >DOMDocument *doc = > > implementation->createDocument(namespace, root_name, 0); > >DOMElement *elem = doc->getDocumentElement(); > >elem->setAttribute(xmlns, namespace); > >XMLCh *serialized = writer->serialize(elem); > > > >o elem contains the xmlns-attributes > >o serialized shows the xmlns-attribute TWICE, which is invalid! > > What is namespace in this case? The actual value of 'namespace' does not matter the effect. I have reproduced double xmlns attr output with different namespace contents, e.g. "namespace", "http://www.somedomain.local";, "http://www.w3.org/2001/XMLSchema"; or "http://www.w3.org/1999/XSL/Transform";. > Are you aware that it has to be > something specific to count as a namespace attr? ?? > It is a common > mistake to think that xmlns attrs are required when you are creating > a document in memory. They are not. The serializer will sort that out > for you. The only time you would create them is if you wanted to bind > specific prefixes or give a specific default namespace. Well, I don't interpret the contents of the DOM tree - I just view it from different viewpoints and let people edit and always produce well formed output (via DOMWriter). Doing this, I realized the described significant difference between the representations of a newly created tree and the reparsed output, iff I provide a namespace during creation. And I can't believe that this was intended, so I endeavor for reporting it as a bug. (It doen't harm too much, since I can live with the described workaround, but the namespace argument of DOMImplementationLS::createDocument seems rather useless to me ;) Regards, Axel -- Humboldt-University, Berlin Institute for Computer Science Signal-Processing and Pattern-Recognition Dipl.-Inf. Axel Weiss Rudower Chaussee 25 D 12489 Berlin-Adlershof +49-30-2093-3050 ** www.freesp.de ** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
