Rob, If I understand your description of the issue correctly, this change should fix that. Instead of merely adding the namespace prefix to the signature of the generated export function, this fix also adds the namespace prefix definition, too. In other words, in addition to adding "xxx:" to the namespace_ parameter, it also adds, for example, "xmlns:xxx="http://www.a.b/example/xxx"; to the namespacedef_ parameter.
I'll send replacement files for you to try attached to a separate email. If that's what we need, please give this fix a try. If not, and if I have that wrong, you'll need to rub my nose in it one more time. Perhaps this change will produce a few unneeded namespace definitions, but I believe and am hoping that will not be a problem. Dave On Tue, Jan 23, 2018 at 02:42:06PM -0800, Rob Calvert wrote: > Thanks for continuing to investigate my namespace issue. I tried out > the new generateDS today. The good news is that some of the changes in > the generated oadr_20b.py corresponded to workarounds that I’d been > making by hand. But I’m still running into at least one of the issues > that I'd mentioned previously: the intervals class lacks a strm > namespacedef. > > The old generateDS creates the following intervals.export() > definition: > > def export(self, outfile, level, namespace_='oadr:', name_='intervals’, > namespacedef_='xmlns:oadr="http://openadr.org/oadr-2.0b/2012/07"; > xmlns:ei="http://docs.oasis-open.org/ns/energyinterop/201110"; ‘, > pretty_print=True): > > The new generateDS creates an intervals.export() definition in > which the namespace_ default is ‘strm:’, which is more correct: > > def export(self, outfile, level, namespace_=’strm:', name_='intervals’, > namespacedef_='xmlns:oadr="http://openadr.org/oadr-2.0b/2012/07"; > xmlns:ei="http://docs.oasis-open.org/ns/energyinterop/201110"; ‘, > pretty_print=True): > > But regardless of whether the namespace_ default is oadr or strm, I > still need to add a strm namespacedef to the definition, i.e.: > xmlns:strm="urn:ietf:params:xml:ns:icalendar-2.0:stream”. If I don’t > add that namespacedef, the XML that’s built will fail validation > (XMLSyntaxError: Namespace prefix strm on intervals is not defined) if > I try to convert the XML string to an etree (lxml.etree.fromstring). > > I see below that you’ve mentioned my ability to define a > GenerateDSNamespaceDefs dictionary. Should I use that dictionary to > create a custom set of namespacedefs for the intervals class? > > Rob Calvert > Kisensum > 510-759-1838 > > > On Jan 22, 2018, at 7:38 PM, Dave Kuhlman <dkuhl...@davekuhlman.org> wrote: > > > > Rob, > > > > I might have a fix for our namespace prefix problem. Referencing > > your earlier message: > > > >> The PayloadFloat class exports tags in the “oadr” namespace; it > >> should export tags in the “ei” namespace. The PowerReal class > >> exports tags in the “oadr” namespace; it should export tags in the > >> “power” namespace. > >> The intervals class lacks a “strm” namespacedef. > > > > This fix results in lots of differences (between the old and new > > versions) when I run oadr_20b.xsd through it. So, if it seems to be > > doing the right thing, we'll still have to do some serious checking > > to make sure that it has not introduced undesired behavior. > > > > Here are a few comments: > > > > 1. There was actually some support for manually controlling the > > namespace prefix for exported content. In the case of the Open > > ADR schema, this would involve so much work that it would not be > > very helpful. Still, you may want to be aware of it. See this: > > > > http://www.davekuhlman.org/generateDS.html#adding-custom-exported-attributes-and-namespace-prefix-definitions. > > And, also search for "GenerateDSNamespaceDefs_" in one of your > > generated files. > > > > 2. I do not have an XML document that is an instance of the Open ADR > > schema. So, I am not able to actually test this change. > > However, it does *seem* to produce the difference in the > > generated PayloadFloatType class that we want to see. > > > > 3. FYI, here is how this change works: process_includes.py has been > > modified so that it collects a dictionary that associates > > xs:element and xs:complexType names that are at at the top level > > and associates those names with the target namespace in which > > they are defined. Since process_includes.py mashes everything in > > all the documents in a schema into a single document, that > > information was formerly being lost. > > > > I've attached the two files that have changed to a separate message. > > If and when you have time, please give it a try, and let me know > > about whether it fixes the problem we are focused on and whether it > > introduces any new problems etc. > > > > I need to do additional testing before I push these changes to the > > Bitbucket repository. > > > > Dave > > > > > > -- > > > > Dave Kuhlman > > http://www.davekuhlman.org > -- Dave Kuhlman http://www.davekuhlman.org ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
