← Prev in month ← Prev in thread
Next in thread → Next in month →

EMIX package structure and file names

From
Anne Hendry
Date
2011-06-12T19:01:00+00:00
ID
Thread
EMIX package structure and file names
I've been thinking for some time that our file names will need to be  formalized before a final release, assuming this would be done in the  final revisions.  Since we are in the process of adding/removing xsd  files and this hasn't been discussed yet I thought I'd bring it up now  because it may be impacted by the namespace discussion.  In OASIS I've been used to seeing all TC file names and directories  begin with the TC name (or abbreviation - in our case 'EMIX') followed  by any additional descriptive strings.  I'm also used to the file names  containing the version.
This conforms with the OASIS TC naming  guidelines and clearly identifies the distribution origin of the files.
This becomes more important as you begin to release update versions.  Here are some examples:  Secutiry Assertion Markup Language TC:
saml-schema-assertion-2.0.xsd Universal Business Language TC:
UBL-CommonBasicComponents-2.1.xsd Service Component Architecture BPEL TC:
sca-bpel-extensions-1.1-cd02.xsd  I propose we construct our file names similarly, prefaced with 'EMIX',  and followed with more fine-grained identifying strings (power,  resource, etc), and version number.  In addition, I'd like to propose we formalize our package structure.
Right now we create a zip file containing the spec and another zip file  containing the schema, and embed one inside the other.  I think that  when someone receives a zip file and unpacks it all the artifacts should  be available without having to dig into the distribution to unpack  (unzip) more files.  It should all be done after you unpack the first zip.  So, to summarize, I propose:  A. package and file names that reflect the TC name and version, as  exampled above  B. Package structure hierarchy such as: / (root directory name beginning with TC name and version, etc) - specification files (multiple formats) - / schema subdirectory - / examples subdirectory - / ... (any other subdirectories needed to hold artifacts that are not  the specification) that are all created and populated by unpacking the top level zip file.  If we are only distributing the specs in a zip and pointing everyone to  the RDDL to get the schema and any other artifacts, then the structure  will be moot.  But if we intend to distribute both spec and schema or  other artifacts at the same time it would be great to have them  organized as above.  The file naming is relevant regardless.  -Anne
← Prev in month ← Prev in thread
Next in thread → Next in month →