EMIX package structure and file names

[Anne Hendry <ahendry@pacbell.net>]

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