Drea Mr Shafie, Thank you for your detailed answer!
- If you say, that XXE does an *acceptable job* when all namepaces and their prefixes are declared in the DTD as attributes with a fixed default value for all the possible root elements of a document, do you mean by that: With the next release of XXE our documents will (should) be saved as valid xml documents? - Is it an easy "operation" to switch from a dtd to a W3C Schema for instance using Altova XMLSpy dtd-schema-conversion. If this is the case, we could *maintain* our dtd but convert the dtd for *use with XMLmind* to a Schema. If the conversion is more than just "blindly pressing one button", a schema is (presently) not an option for us, as we have no W3C-schema-knowledge at all. Kindest regards Thomas Dumm > -----Urspr?ngliche Nachricht----- > Von: Hussein Shafie [mailto:hussein at xmlmind.com] > Gesendet: Freitag, 2. Oktober 2009 12:44 > An: Thomas Dumm > Cc: xmleditor-support at xmlmind.com > Betreff: Re: [XXE] When does XMLmind write the DCMI namespace URI? > > Thomas Dumm wrote: > > Dear Mr Shafie, > > > > How can I prevent XMLmind from writing the DCMI namespace URI > > (xmlns:dc=http://purl.org/dc/elements/1.1/) in my dc-elements? > > What determines in XMLmind that DCMI namespace URI are inserted? > > > > If I open in Oxygen an xml-file that contains the DCMI > namespace URI > > in the dc-elements I get the error message: > > E [Xerces] Attribute "xmlns:dc" must be declared for element type > > "dc:contributor". > > > > I must admit, that I am a bit lost here. Should the dc-namespace be > > written in the dc-elements or not? > > If I generate an xml-file with Arbortext the DCMI namespace URI is > > *not* written in the dc-elements. > > > > In the dtd I have the root-element <Collection> with: > > > > <!ELEMENT Collection (MetaData?, (Digest | MetaFrame | > Facts | Feature > > )*)> <!ATTLIST Collection CollectionDescription CDATA > #FIXED "emnemics > > GreenCollection R2" > > CollectionRights CDATA #FIXED "(c) emnemics ag switzerland, > all rights > > on structure reserved, www.emnemics.ch" > > CollectionIdentifier CDATA #FIXED "02-gre-r2-nil0000" > > xmlns:dc CDATA #FIXED "http://purl.org/dc/elements/1.1/" > > xmlns:m CDATA #FIXED "http://www.w3.org/1998/Math/MathML"> > > > > A dc-elements are the defined by: > > > > <!ELEMENT dc:temporal (#PCDATA)> > > <!ATTLIST dc:temporal > > type (01 | 02 | 03 | 04 | > 05 | 06 | > > 07 | > > 08 | 09) #IMPLIED> > > > > > > So should the DCMI namespace URI be written in our > dc-Elements, or not? > > > > As we start to load files into our cms, I fear that these > minor(???) > > differences will show up an might cause problems. > > > > I know, that this question is more about dtd than about > XMLmind, but > > you might know a the :-) > > > > XMLmind XML Editor is not good at dealing with *DTDs* making > use of namespaces and will never be. (Of course, no problem > with W3C XML Schema and RELAX NG schema). However we'll try > to improve the situation and thus fix your problem, in next release. > > [1] Oxygen/Xerces is right at reporting an error. But the > error message is totally wrong. It should be something like: > "validation error: the dc:contributor element cannot have a > xmlns:dc attribute". > > [2] Arbortext is right by not generating > xmlns:dc="http://purl.org/dc/elements/1.1/" on for example a > dc:contributor element. Your DTD does not allow to do this. > > [3] XXE should not generate > xmlns:dc="http://purl.org/dc/elements/1.1/" > on, for example a dc:contributor element, because your DTD > specifies fixed default attribute value > xmlns:dc="http://purl.org/dc/elements/1.1/" only for the root > elements of your documents (e.g. Collection). > > I think it worked fine in XXE 4.0 and 4.1 and that we broke > something in a subsequent release. > > In a nutshell, XXE is not good at dealing with DTDs making > heavy use of namespaces. For XXE to do an acceptable job, all > the namepaces and their prefixes must be declared in the DTD > as attributes with a fixed default value for all the possible > root elements of a document. > > > >

