Thanks for getting back to me. 1) The test are as good as I can get them without input. I can make all 3 pass, but wanted to verify that the original behavior was intentional, not "failing silently":
- For the two tests with missing files, I checked the entire Mercurial history and they've never existed. I can simply ignore the stderr and let the tests pass/fail based on the output comparison. - I have no idea on the third test. The difference looks deliberate (like part of a SimpleTypes patch), but I didn't feel qualified to make the executive decision since I'm just getting my arms around the tool. 2) I wouldn't want you to waste your time trying to figure HL7 out. It's free if you agree to the ToS, but it's ~1600 XSD files that require a lot of background knowledge to sort out. Maybe easier to give me your recollection of the django generator... is it tightly coupled to the generateDS syntax or would it pick up changes (like inheritance) if introduced somehow (by hand or programmatically). 3) I've been working with/on the tool the last few days. I think it'll save me development time so I got the green light to invest some energy into it. I'd like to propose breaking the tool down into smaller pieces with well-defined intermediate formats. That way I could add a step that rewrites an intermediate format. Hopefully I could use all the same downstream tooling but get the layout I want/need. Are you open to something like this? Clayton Daley Ambassador Software Works clay...@ambsw.com 614.448.1519 On Thu, Sep 1, 2016 at 4:54 PM, Dave Kuhlman <dkuhl...@davekuhlman.org> wrote: > 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 > -- *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.*
------------------------------------------------------------------------------
_______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
