Dave Kuhlman
--- Begin Message ---
…and again there was a delay, longer this time: sorry. My first try at testing 
your changes failed, but I suspected a cockpit error on my end. Proving that it 
was my error took longer than it should have, but in the end, yes: the test 
failure was due to my mistake, not yours. Your namespace-related changes in 
generateDS.py and process_includes.py have done the trick perfectly: I can now 
use my generated Python module with no need for tweaks or workarounds. Thank 

— Rob Calvert

> On Jan 31, 2018, at 7:59 AM, Rob Calvert <r...@kisensum.com> wrote:
> Sorry for the delay in responding; yesterday was crazy busy due to a flawed 
> software deployment. Today should be less stressful, so I’ll take the 
> adjusted version of generateDS out for a spin. It sounds like you’ve nailed 
> my issue! — Rob
>> On Jan 29, 2018, at 2:22 PM, Dave Kuhlman <dkuhl...@davekuhlman.org> wrote:
>> 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

--- End Message ---
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

Reply via email to