Rob,

Thanks for explaining the problem.  That helps.  Give me a couple of
days to look into it.

The change that I sent to you yesterday adds code that collects a
dictionary of the name and namespace prefix of each xs:element and
xs:complexType.  So, it should be reasonably easy to also collect
the namespace itself, and then use that namespace when generating
the namespacedef_ parameter for the export method.

I can't work on it tomorrow.  We're going to San Francisco to visit
the Legion of Honor art museum.  Got to see Rodin and Klimt,  But,
I'll try to work on it on Friday.  If it's do-able, I hope to have
something next week.

More later.

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

Reply via email to