[Smwg] Registries for Simple Schedule. (Our action from yesterdays webex)

Tue Apr 21 00:29:28 UTC 2015

John, Colin,

I definitely agree with an indication that the schema is a normative artifact. So I'm all for updating the book in that regard.

With regard to the identifier registries (what John calls the non-XML registries) I vote for these to be named with respect to the cross support services area as a) conceptually this is more in keeping with the functional resource model and b) the general body of work is aimed at cross support and so it seems that in the monitor data if we are reporting registered antenna identifiers, etc, those kind of things should draw from the same registry (of course, that is not be confused with registry of monitored data parameters, but in this case it is the registered values of that registered parameter -- are we having fun yet? )

I agree with John's comment on  the File/Description/Reference triple for the XML registry.

Best regards,

-Erik

-----Original Message-----
From: John Pietras [mailto:john.pietras at gst.com] 
Sent: Monday, April 20, 2015 12:17 PM
To: Colin.Haddow at esa.int
Cc: Barkley, Erik J (3970); CCSDS Service Mgmt WG
Subject: RE: [Smwg] Registries for Simple Schedule. (Our action from yesterdays webex)

Colin,
As far as the non-XML registries, I have no quibbles with your suggestions.

Here are my comments regarding the XML schema registry:
1.	 I think you meant to call the registry "SCCS-SM Information Entity XML Schemas" (we don't have anything defined as "Data Entity").
2	I assume that your comment about changing the name of registries from "SCCS-SM" to "CSS" was meant only  for Originating Organization, User, and Station and Antenna Reference.  I don't think that making the change in the XML schema registry is a good idea. We only have Information Entities in SCCS-SM. If and when CSS ever has XML schemas that are *not* related to  ISCCS-SM Info Entities, I would recommend that they be put into a separate registry. 
3. I was initially confused by the proposed structure for each SCCS-SM Information Entity XML Schema entry"
" File                    Description
Reference
The schema file [Type: FILE]  A textual description of the schema purpose
[Type:: STRING*1024]    Reference number of the appropriate book where the
schema is defined [Type: STRING*16]".

But if it's meant to say
" File                   The schema file [Type: FILE]
 Description     A textual description of the schema purpose
Reference       [Type:: STRING*1024]    Reference number of the appropriate book where the
                            schema is defined [Type: STRING*16]"

then I'm fine with that.

The last sentence above, " Reference number of the appropriate book WHERER THE SCHEMA IS DEFINED [capitalization mine for emphasis]" mad me realize that the book does not (to my knowledge) state that the schemas themselves are normative. We had a problem with SGSS and SCCS-SM Blue-1, in that the SGSS Contractor did not realize that the schemas were intended to be normative and so created their own (which is now all irrelevant in that SGSS has abandoned SCCS-SM almost completely).

I have put some additional material in the attached update to the Simple Schedule draft to enforce the normative nature of the Simple Schedule, SM Info Entity, and CCSDS Timecodes schemas for application to Simple Schedules. The associated changes occur in section 1.4 (c), (d), (f), and (g), 3.1, a new 3.6, a new section A3 of Annex A, C2, and D2.

Finally, I noticed that the progression in Annex A was:
A1 GENERAL
A1.1  SERVICE MANAGEMENT INFORMATION ENTITY CONTENT/STRUCTURE
A1.1.1  OVERVIEW
Etc., with no A2. 

I think that it should be 
A1 GENERAL
A2  SERVICE MANAGEMENT INFORMATION ENTITY CONTENT/STRUCTURE
A2.1  OVERVIEW
Etc.

I've changed it to be that way in the attached draft. That's how the new XML schema-relate subsection of Annex came to be labeled A3. If you disagree with this renumbering then of course you can ignore it.

Best regards,
John

-----Original Message-----
From: smwg-bounces at mailman.ccsds.org [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Colin.Haddow at esa.int
Sent: Wednesday, April 15, 2015 9:21 AM
To: John Pietras
Cc: erik.j.barkley at jpl.nasa.gov; CCSDS Service Mgmt WG
Subject: [Smwg] Registries for Simple Schedule. (Our action from yesterdays webex)

Hi John,
                 currently in the Simple Schedule book the following repositories are identified;

   SCCS-SM originatingOrganization
   SCCS-SM user (which cross-references the SANA Spacecraft Identifiers
   Registry)
   SCCS-SM stationAndAntennaRef

Now I've had a look at the SANA procedures yellow book and can't see anything related to naming conventions so it looks like we're relatively free in that respect. I've also had a look at what the nav and data archive guys are doing with thier XML schemas in the registry and they're putting all the schemas under one registry (as you're probably aware). This being the case I suggest the following approach;

for the Schemas we create the following registry;

SCCS-SM Data Entity XML Schemas - this would have the following structure;

File                    Description
Reference
The schema file [Type: FILE]  A textual description of the schema purpose
[Type:: STRING*1024]    Reference number of the appropriate book where the
schema is defined [Type: STRING*16]

for the registries from the Simple Schedule book I'd rename these slightly to remove the concatenation/camel case (will need a minor edit to the book) such that these become;

SCCS-SM Originating Organization
SCCS-SM User
SCCS-SM Station and Antenna Reference

This approach should be extensible to handle any other registries that  we are likely to come up with in the scope of Service Management. Only question I have (and perhaps Erik and Margherita can comment on this) is whether it is better to use the Area, rather than the working group as the initial identifier (i.e. replace SCCS-SM in the above registry names with CSS). The latter approach would perhaps be more consistent with maintaining the registries/schemas at Area level as has been discussed.

Any thoughts ?

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 and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

_______________________________________________
Smwg mailing list
Smwg at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/smwg

--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------

Teach CanIt if this mail (ID 01OgdzJvT) is spam:
Spam:        https://filter.gst.com/canit/b.php?i=01OgdzJvT&m=cd2c267ad1b9&c=s
Not spam:    https://filter.gst.com/canit/b.php?i=01OgdzJvT&m=cd2c267ad1b9&c=n
Forget vote: https://filter.gst.com/canit/b.php?i=01OgdzJvT&m=cd2c267ad1b9&c=f
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS