--
Dave Kuhlman
http://www.davekuhlman.org
--- 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
you!
— 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
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
