[Smwg] Registries for Simple Schedule. (Our action from yesterdays webex)
Shames, Peter M (312B)
peter.m.shames at jpl.nasa.gov
Tue Apr 21 16:21:09 UTC 2015
I really want to encourage you all to think about which of these
registries need to be promoted not just to an Area level, but to a CCSDS
global level. In particular, any of the registries that define member
agencies, observers, service providers, related points of contact, and
facilities / assets that those organizations own should, in my opinion, be
treated as "agency" or "organization" type registries. The implication
being that any standards that need to reference on of the organization
registries should do that directly, as opposed to creating a new,
separate, "Area" or "Working Group" registry that holds some subset of
this information.
This is the approach that I am trying to promote across all of the Wgs
that have similar issues, and there are several. If we can all move in
that direction it will be better for all of CCSDS in the long run.
Regards, Peter
On 4/20/15, 5:29 PM, "Barkley, Erik J (3970)"
<erik.j.barkley at jpl.nasa.gov> wrote:
>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
>
>
>_______________________________________________
>Smwg mailing list
>Smwg at mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/smwg
More information about the SMWG
mailing list