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? (And I'm still interested in answers to #2). Thanks, Clayton On Mon, Aug 29, 2016 at 4:21 PM, Clayton Daley <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.*
------------------------------------------------------------------------------
_______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
