[Smwg] Refactored, Renamed and Updated Schemas and UML Model for Service Management
Colin.Haddow at esa.int
Colin.Haddow at esa.int
Fri Nov 2 14:47:11 UTC 2018
Dear all,
those of you who were in Berlin will recall there was
discussion about naming conventions for various items (files, attributes,
etc.). I've just uploaded updated schemas and UML models into SANA which
reflect these changes and also include the other updates that were
discussed in Berlin. For the Schema naming I've adopted the following
convention;
Directory structure
902 Schema All service management books are
in the 902 series (except for TGFT)
902x01 Schema files for Simple Schedule
902x02 Schema files for Planning
Information Formats
902x03 Currently unassigned
902x04 Schema files for Service Package
Data Formats
902x05 Schema files for Service Agreement
and Configuration Profile Data Formats
902x06 Schema files for Space Link Event
Sequence Data Format
902x07 Schema files for Service Catalog
902x08 Schema files for Service
Accounting
902x09 Schema files for Service
Management Utilization Request Formats
902x10 Schema files for Management
Services
902x11 Schema files for Best Practices
902x12 Schema files for Service
Management Common Data Entities
902x13 Schema files for Abstract Event
Definition
For the naming convention of the schema files themselves I've adopted the
following
902xNNcM[_OO][pP]-SchemaNameInCamelCase.xsd where
NN is the book number in the 902 series. Note that this is 2 digits with a
leading "0" if required.
c is the colour of the book, i.e.
w for White
r for Red
m for Magenta
b for Blue
M is the issue of the book
[_OO] is an optional minor version prefixed with an underscore, only
applies to white and red drafts. Note again this is 2 digits with a
leading "0" if required.
[pP] is used if the schema has been updated because of a pink sheet, only
applies to blue and magenta.
p indicates it is an update due to a pink sheet
P is the number of the pink sheet
A minus sign "-" is used to seprate the identifer part from the alphabetic
part of the name.
"Schema" is always the first part of the name
The alphabetic part of the name is written in camel case.
There is no white space in the file name (This is because when including
the schema name in an xml file using the xsi:schemaLocation attribute
white space in the file name caused problems. (I haven't been able to find
a way around this but if anybody knows one please let me know.)
This results in names as shown below;
902x01b1p1-SchemaCssmSimpleSchedule.xsd This is
Blue Book Version 1 of the Simple Schedule, updated with Pink Sheet 1
(which does not exist - yet...)
902x02w0_20-SchemaCssmPlanningInformationFormats.xsd This is
White Book Draft 0.20 of the Planning Information Formats.
For the UML Model I've adopted a similiar approach to the directory and
naming conventions (obviously without the use of "Schema" in the file
names)
The zip files containg the schemas and UML models can be found at the URLs
below. Note that in these I've included a slightly modified version of the
Simple Schedule schema and UML model that fits in with the directory and
file naming conventions outlined above. This is labeled as 902x01b1p1-...
Schema zip file:
https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Schemas/902%20Schema%2020181102.zip
UML model zip file:
https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/UML%20Model/902%20UML%20Model%2020181102.zip
We can discuss any comments/critiscims about this appraoch at the next
WebEx.
The ".project" files in the schema sub-directories are Eclipse project
files. I use Eclipse for editing and validating the schema files.
One final thing to point out is that those of you who look at the SMURF
schema will notice that it has the following include statements
<xsd:include schemaLocation=
"../902x06/902x06w0_00-SchemaCssmSpaceLinkEventSequenceDataFormat.xsd"/>
<xsd:include schemaLocation=
"../902x05/902x05w0_00-SchemaCssmServiceAgreementAndConfigurationProfileDataFormats.xsd"
/>
<xsd:include schemaLocation=
"../902x04/902x04w0_00-SchemaCssmServicePackageDataFormats.xsd"/>
i.e. it has dependencies on the Schema files for Service Package Data
Formats, Service Agreement and Configuration Profile Data Formats and
Space Link Event Sequence Data Format. This is because the SMURF is
required to be able to submit complete Service Packages, Configuration
Profiles and Event Seqeunces. In view of this I suggest that we leave
these dependencies rather than making them common data structures beacuase
if we make them common data structures the common data structures book
will efectivly need to contain be the Service Package Data Formats,
Service Agreement and Configuration Profile Data Formats and Space Link
Event Sequence Data Format Books. Not a good idea...
You will note that I've made some assumptions about what these 3 schemas
will be called, if the Book Captains for these books would prefer the main
schema name to be changed please let me know and I'll update things
accordingly...
Cheers for now,
Colin
---------------------------------------------------------------------------------------------------------
Dr. Colin R. Haddow,
HSO-GI, European Space Agency,
European Space Operations Centre,
Robert-Bosch-Str 5,
64293 Darmstadt,
Germany.
Phone; +49 6151 90 2896
Fax; +49 6151 90 3010
E-Mail; colin.haddow at esa.int
---------------------------------------------------------------------------------------------------------
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20181102/9c44c711/attachment.html>
More information about the SMWG
mailing list