Hello Dave, this patch works form me.
To the "repeating" of namesapces, I think this could only happen if one is using more than one namespace. And using more namesapces, you have to use namespaceprefixes and with these prefixes you have the possibility to use different namespaces 😉 <root xmlns:h="http://www.w3.org/TR/html4/"; xmlns:f="https://www.w3schools.com/furniture";> <h:table> <h:tr> <h:td>Apples</h:td> <h:td>Bananas</h:td> </h:tr> </h:table> <f:table> <f:name>African Coffee Table</f:name> <f:width>80</f:width> <f:length>120</f:length> </f:table> </root> Regards, Bernd C:\source\python\test\>python test18.py <?xml version="1.0" encoding="UTF-8"?> <retainedDataMessage xmlns="http://uri.etsi.org/02657/v1.18.1#/RetainedData";> <rdHeaderId>0.4.0.2.3.0.14</rdHeaderId> <retainedDataHeader> <requestID> <countryCode>DE</countryCode> <authorisedOrganisationID>045</authorisedOrganisationID> <requestNumber>1234567</requestNumber> </requestID> <cSPID>49045</cSPID> <timeStamp>20181213090344+0100</timeStamp> </retainedDataHeader> <retainedDataPayload> <requestAcknowledgement/> </retainedDataPayload> </retainedDataMessage> XML well formatted XML valid -----Ursprüngliche Nachricht----- Von: Dave Kuhlman <dkuhl...@davekuhlman.org> Gesendet: Dienstag, 11. Dezember 2018 22:22 An: Zimmermann, Bernd <bernd.zimmerm...@plusnet.de> Cc: François Guimond <fguim...@gmail.com>; generateds-users@lists.sourceforge.net Betreff: Re: [Generateds-users] New export bug in 2.30.8 ? François, Bernd, et al, This might be a fix. Or, it might not. It certainly needs more testing. See attached. The attached is a patch against version 2.30.10. Even if it is not the correct fix, it does point us at the region of code where a fix is likely needed. Part of the problem is that it is difficult to determine in advance whether a namespace prefix definition needs to be repeated on enclosed elements. For example, is it possible that: - ElementA needs namespace prefix definition "http://aaa"; - ElementA contains ElementB which is in a different namespace. - ElementB contains ElementC which is in namespace "http://aaa";. Or, is that pathological? Maybe, but isn't all XML pathological? Dave On Tue, Dec 11, 2018 at 12:52:20PM +0000, Zimmermann, Bernd wrote: > Hello Francois, > > I just tried with the --no-namespace-defs option: > > # Generated Tue Dec 11 13:35:53 2018 by generateDS.py version 2.30.8. > > # Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 > bit (AMD64)] > > # > # Command line options: > # ('--no-namespace-defs', '') > # ('-o', 'NP2V18Test2.py') > > with no other result. > > The generated .py files are identical except for the header … > > So again, the xml file gets the namespace printed in all tags. > > Omitting a defaultns in the generatedsnamespaces.py file results in an > invalid xml > > missing the namespace in the root element. > > Exporting with parameter namespacedef_=’xmlns: …’ again results in > printing > > the namespaces in all xml tags. > > > > So as I wrote in my message before, I think the intention of using > namespaces is, > > to declare them just in the root element and not repeating it in > every > > xml tag. Multiple namespaces are handled by the namespaceprefix_ value. > > > > I would still suggest not to pass the namespacedef_ to the children. > > > > Best regards, > > Bernd > > > > Von: François Guimond <fguim...@gmail.com> > Gesendet: Dienstag, 11. Dezember 2018 04:18 > An: Zimmermann, Bernd <bernd.zimmerm...@plusnet.de> > Cc: dkuhl...@davekuhlman.org; generateds-users@lists.sourceforge.net > Betreff: Re: [Generateds-users] New export bug in 2.30.8 ? > > > > Bernd, > > > > Ok, I got something similar. ( it always happens 5 min after the send > button is pressed... 😊 ) > > > > use the --no-namespace-defs option when you call generateds.py to avoid > the problem. > > > > I will investigate later this week. > > > > Le lun. 10 déc. 2018 à 21:59, François Guimond <fguim...@gmail.com> a > écrit : > > Hi Bernd, Dave, > > > > The problem Bernd describe is not related to namespaceprefix_, but > namespacedef_ instead. > > > > The change was introduced in revision #278. > > > > Now I didn't fully analyzed what is going on, but with the model I am > working with I am using namespacedef_ of my export function, and I don't > get the same behavior. > > > > So Bernd could you try to change your export function call to something > like this: > > > > output = StringIO() > output.write('<?xml version="1.0" encoding="UTF-8"?>\n') > testxml.export(output, 0, namespaceprefix_='', > namespacedef_='xmlns="http://uri.etsi.org/02657/v1.18.1#/RetainedData";' > ) > > > > and tell us if it makes any difference? That should guide the the > investigation if it's related to GenerateDSNamespaceDefs or not. > > > > Thanks > > François Guimond > > > > NB as for reverting 2.30.8, I agree your current output is not ideal, > but I believe your XML is still valid, so let us investigate... > > > > Le lun. 10 déc. 2018 à 13:48, Zimmermann, Bernd > <bernd.zimmerm...@plusnet.de> a écrit : > > Just a follow up to my last message: > > Looking via bitbucket I think, that we are talking about this change: > > +Version 2.30.4 (11/06/2018) > +- A fix from François Guimond for passing namespaceprefix_ to > + ``self.exportChildren``. Thanks François. > > > https://bitbucket.org/dkuhlman/generateds/commits/f75d7ec327a5e9d839cb > b73e7995c30461850e72#chg-generateDS.py > > which introduced the passing of namespaceprefix_ to childen. > > As I showed below, this results in printing the namespace in every xml > tag > which is hard to read and in my opinion unnecessary. > > So I would vote for the old version, only keeping the namespace in the > top element. > > Another possibility would be a check if there are default namespaces > for > different elements. > > Regards, > Bernd > > -----Ursprüngliche Nachricht----- > Von: Zimmermann, Bernd > Gesendet: Montag, 10. Dezember 2018 10:39 > An: 'Dave Kuhlman' <dkuhl...@davekuhlman.org>; generateds-users > <generateds-users@lists.sourceforge.net> > Betreff: New export bug in 2.30.8 ? > > Hello, > > just updated from 2.29.24 to 2.30.8 and discovered a maybe bug in the > export function. > > 2.29.24 > was: def export(self, outfile, level, namespaceprefix_='', > name_='Target', namespacedef_='', pretty_print=True): > > 2.30.8 > is: def export(self, outfile, level, namespaceprefix_='', > namespacedef_='', name_='Target', pretty_print=True): > > well Ok, change of the parameter order, but there must be something > wrong: > > test code: > > requestID = Natparas2.RequestID('DE','045','1234567') > dt = datetime.datetime.now().replace(microsecond=0) > localtime = dt.astimezone(pytz.timezone("Europe/Berlin")) > timestamp = str(localtime).replace(" > ","").replace("-","").replace(":","") > cSPID = '49045' > retainedDataHeader = Natparas2.RetainedDataHeader(requestID, > cSPID, timestamp) > requestAcknowledgement = Natparas2.RequestAcknowledgement() > retainedDataPayload = Natparas2.RetainedDataPayload(None, > requestAcknowledgement) > testxml = > Natparas2.RetainedDataMessage('0.4.0.2.3.0.14',retainedDataHeader, > retainedDataPayload) > > output = StringIO() > output.write('<?xml version="1.0" encoding="UTF-8"?>\n') > testxml.export(output, 0, '', 'retainedDataMessage') > > From 2.29.24: > <?xml version="1.0" encoding="UTF-8"?> > <retainedDataMessage > xmlns="http://uri.etsi.org/02657/v1.18.1#/RetainedData";> > <rdHeaderId>0.4.0.2.3.0.14</rdHeaderId> > <retainedDataHeader> > <requestID> > <countryCode>DE</countryCode> > <authorisedOrganisationID>045</authorisedOrganisationID> > <requestNumber>1234567</requestNumber> > </requestID> > <cSPID>49045</cSPID> > <timeStamp>20181210101011+0100</timeStamp> > </retainedDataHeader> > <retainedDataPayload> > <requestAcknowledgement/> > </retainedDataPayload> > </retainedDataMessage> > > as it sould be. > Note: using default ns for RetainedDataMessage: > > GenerateDSNamespaceDefs = { > "RetainedDataMessage": > 'xmlns="http://uri.etsi.org/02657/v1.18.1#/RetainedData";', > } > > defined only for the xml tag < RetainedDataMessage> and as the output > shows, it is only printed in line 2 of the output. > All other xml tags are without NS. > > From 2.30.8: > <?xml version="1.0" encoding="UTF-8"?> > <RetainedDataMessage > xmlns="http://uri.etsi.org/02657/v1.18.1#/RetainedData";> > <rdHeaderId>0.4.0.2.3.0.14</rdHeaderId> > <retainedDataHeader > xmlns="http://uri.etsi.org/02657/v1.18.1#/RetainedData";> > <requestID > xmlns="http://uri.etsi.org/02657/v1.18.1#/RetainedData";> > <countryCode>DE</countryCode> > <authorisedOrganisationID>045</authorisedOrganisationID> > <requestNumber>1234567</requestNumber> > </requestID> > <cSPID>49045</cSPID> > <timeStamp>20181210102515+0100</timeStamp> > </retainedDataHeader> > <retainedDataPayload > xmlns="http://uri.etsi.org/02657/v1.18.1#/RetainedData";> > <requestAcknowledgement > xmlns="http://uri.etsi.org/02657/v1.18.1#/RetainedData"/> > </retainedDataPayload> > </RetainedDataMessage> > > Difference: > > ALL other xml tags get the defaultNS which is wrong here, because only > <RetainedDataMessage> shall have it. > All other xml tags should go without defaultNS. > > Code compare shows: > > in 2.29.24: > self.exportChildren(outfile, level + 1, namespaceprefix_='', > name_='Target', pretty_print=pretty_print) > > in 2.30.8: > self.exportChildren(outfile, level + 1, namespaceprefix_, > namespacedef_, name_='Target', pretty_print=pretty_print) > > here the namespacedef_ is added, but if the children is another xml > tag with another name like <retainedDataHeader>, and the defaultNS ist > wrong here because it is not valid and only valid for > <RetainedDataMessage>. > So it must be checked in advance if it is valid here or not and if is > defined for the given tag name. > > Please fix it 😉 > Perhaps either roll back to the old behaviour or please implement a > name check in the children print function to check if the children xml > tag name hat got a defaultNS defined for its tag name. > > Regards, > Bernd > > _______________________________________________ > generateds-users mailing list > generateds-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/generateds-users -- Dave Kuhlman http://www.davekuhlman.org _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
