On Tue, Aug 30, 2016 at 11:19:19AM -0500, Clayton Daley wrote: > OK. I finally read through the "One Per" section and I think it > answers my first question, actually recommending the strategy I propose > in 1(b). However, it also states: > > At least one element definition in an included/imported module must > be a root element definition in order to cause a module to be generated > for that schema > Is there a fundamental architectural reason why this must be true? > Most of my included files are common type definitions with no roots, > but I want/need them compiled to classes. If I were interested in > relaxing this constraint (e.g. in a PR), am I going to run into serious > issues that would force me to rewrite much of the package?
Clayton, I'll have to study the one-per facility a bit more, but, my belief is that the reason for that requirement (for a root element type) is that during one-per processing it uses the same code as is used for normal processing. That normal processing needs to generate a module that can (1) parse and build data structures starting at a root element and (2) export to XML by starting at a root element. In contrast, the modules you'd like to generate are library modules and do not need those two capabilities. (Am I right about that?) So, we should be able to turn that off and by doing so, not generate the parse(), parseEtree(), parseString(), and parseLiteral(). I'll look into it. OK, I looked. Generating those parse functions is done in function generateMain() in generateDS.py. Turning it off should be simple, let's say by passing in a value of None for the parameter root or checking some flag or other. The question is, when to do that? Could we always do that when the --one-file-per-xsd command line option is used? Or, do we need yet another command line option, perhaps, --no-root-elements or maybe --no-generate-parse-functions, or whatever. By the way, I looked at your pull request for the modifications to the unit tests. That work looks promising. Let me know when you think you are finished and I'll merge it and test it. Thanks for this work. > (And I'm still interested in answers to #2). That would take me quite a bit more time and study. I did go looking for those HL7v3 XML schemas. I found the Web site, I believe, but not the schemas. Perhaps they are protected and not publicly available. If I had those, you *might* be able to explain to me what you mean and what you want. But, it does sound a bit complex for someone with my modest brain power. Dave > Thanks, > Clayton > On Mon, Aug 29, 2016 at 4:21 PM, Clayton Daley <[1]clay...@ambsw.com> > wrote: > > Good Afternoon, > We're working with some very large XML structures based on a healthcare > standard known as HL7v3. To date, we've used a library of XPATH calls > to access the data we're interested in. I'm exploring the possibility > of converting them to pure Python (and ideally Django models). HL7v3 > publishes XSD files so it's at least theoretically possible to use > GenerateDS to produce the desired code. > I'd welcome comments from anyone who's tried this, but have a couple > questions to kick off my attempt: > 1) The HL7v3 specification has many files with common imports from a > few "core" files.  > a) Is there a way to compile all (or a subset) of the XSD files at > once, preserving the common imports in the generated classes? > b) If not, can I achieve the desired behavior by creating a new XSD > that imports all of the files of-interest? > c) Can I get GenerateDS to produce multiple files (preferably mirroring > the original file structure)? > 2) The HL7v3 specification is... odd. There are cases where classes > have "inheritance" relationships that aren't specified in the XSD (if > this is even possible). For example: > * Class B is exactly the same as class A.  > * Class D, E, and F are (different) subsets of class B. > > The standard intends all of these to represent the same thing (e.g. a > patient), presenting more or less information depending on the > situation (and as specified by the type in the XSD). Ideally, I'd end > up with a single Django model for the patient and specialized > serializers that would be used when the XSD calls for them. > a) Any idea of GenerateDS will be friendly to this sorts of use? > b) Is there any way to feed inheritance information like this into the > generator? > c) If I hand-modify the generated classes to respect these > relationships, will the Django generator preserve these relationships? > Thanks, > Clayton > > The transmission of protected health information (PHI) and > individually-identifiable personal information (IIPI) is regulated by > federal and/or state privacy laws.  Do not send PHI or IIPI to this > email account.  If you receive an email from this account that > includes PHI or IIPI, (1) immediately delete the email without > printing, forwarding or further distributing the content, and (2) send > an email to this address and report all details of the incident.  Your > cooperation is appreciated. > > References > > 1. mailto:clay...@ambsw.com > ------------------------------------------------------------------------------ > _______________________________________________ > 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
