[Sois-app] RE: Plan for update to SEDS schema Red book (876x0 )

Wed May 6 12:24:18 UTC 2015

This email contains some answers to a selection of Peter Shame's
comments on 876x0  that won't otherwise be straightforwardly addressed
by this round of document updates.

PS: I'm guessing that the rationale for this will become evident, but I
am having trouble understanding, on the surface of it, why any part of
the DAS or DVS SERVICES would appear INSIDE a DEVICE element.  Aren't
these external services that are at least one (or two) levels of
indirection separate from the device itself and how it works.

This is a fair enough conceptual point; the intent is that the DAS and
DVS components specified in the datasheet are used in the specification
(and typically, auto-generated implementation) of the parts of the DAS
and DVS services that correspond to that device.

This is probably best summarised by section 3.2 and 3.3 of the Green
Book
(http://cwe.ccsds.org/sois/docs/SOIS-APP/Meeting%20Materials/2015/Spring
/EDS/TBDx0g1_EDS_and_Common_DoT.2015.03.01.docx):

There is an intent to change the schema in this area, so that instead of
flagging a component as suitable for use in DAS/DVS, you instead flag an
interface as access, functional or message. Then what you would expect
is that, for example, the DAS service for a particular satellite
aggregates together all interfaces flagged as 'access' across all device
datasheets.

But that is associated with the changes to fully support MTS, and so not
in this version of the schema red book.

PS: Does this really mean that EDS does not support any subnetwork other
than SpaceWire?  Seems like an over constrained spec.

That is the current status quo - there are plans to:

*         'move' this part of the schema to the DoT, so that it is
user-extensible with other subnetwork types

*         Add standard terms for (at least) MILBUS subnetworks

Again, that is future work, not in the scope of this document version. 

PS: What is a "hierarchical set of CONSTANT data values"?  And why is
this the only metadata element allowed?

The metadata area is a tree-like structure of named values. They
represent arbitrary facts known about the device (e.g. it's version,
size, etc). There are no current known requirements for any form of
metadata that doesn't fit into that pattern.

PS: Reference CCSDS namespace as registered in SANA.

A 'namespace' within a datasheet is just a partition local to that
datasheet, analogous to a C++ namespace or Java package. It is not
anything intended to have any wider universal visibility; in particular
it is _not_ an XML/XSD namespace.

Possibly it could be renamed to 'package' to avoid that confusion, but
there are no current plans to actually do so.

richard

From: Shames, Peter M (312B) [mailto:peter.m.shames at jpl.nasa.gov] 
Sent: 01 May 2015 18:39
To: Richard Melvin
Cc: r.krosley at andropogon.org; jonathan.j.wilmot at nasa.gov
Subject: Re: Plan for update to SEDS schema Red book (876x0 )

Ok.  Thanks for the info.

I knew there were WG changes, but was not sure who the doc or WG leads
were.  Sounds like you're doing just what is needed.  Good to know.

Let me know if you need anything else.

Peter

Sent from Peter's iPhone 6 

Everything should be made as simple as possible, 

but not simpler.  

~Albert Einstein

On May 1, 2015, at 10:12 AM, Richard Melvin
<Richard.Melvin at scisys.co.uk> wrote:

	Thank you for your time in supporting this activity. It comes
from the results of the CESG poll, where Tom Gannet advised 'Resolution
of the conditions should be negotiated directly with the authors of the
conditions (CCed) and reported back to the CESG'. Hopefully this
'negotiation' should take less effort than a full cycle of raising +
resolving adiditonal RIDs.

	To be clear, I am updating 876x0 (the schema book), in
coordination with Ray, who is the editor for 876x1 (the terms book), and
Jonathan, the WG chair. Certainly I have no objection to these emails
being copied to anyone else they are relevant to.

	Thanks,

	richard

	From: Shames, Peter M (312B)
[mailto:peter.m.shames at jpl.nasa.gov] 
	Sent: 30 April 2015 18:58
	To: Richard Melvin
	Cc: r.krosley at andropogon.org; jonathan.j.wilmot at nasa.gov
	Subject: Re: Plan for update to SEDS schema Red book (876x0 )
	Importance: High

	Richard, et al,

	It occurs to me that good "CCSDS etiquette" would include the
editors of both documents, the WG chair, and possibly even the new AD in
this discussion.   Since two separate editors appear to be involved, and
sorting this out completely is therefore a WG matter, I think that
broader discussion would be a good thing.  Further, since the AD is also
new to the job, I think that keeping him in the loop would also be
useful.  That way everyone gets to buy in and also gets to see the
"CCSDS machinery" in motion.

	If you agree you can copy them on the previous email trail or I
can do it for you.  What would you prefer?

	Thanks, Peter

	From: Richard Melvin <Richard.Melvin at scisys.co.uk>
	Date: Thursday, April 30, 2015 at 6:38 AM
	To: Peter Shames <peter.m.shames at jpl.nasa.gov>
	Cc: Ramon Krosley <r.krosley at andropogon.org>,
"jonathan.j.wilmot at nasa.gov" <jonathan.j.wilmot at nasa.gov>
	Subject: Plan for update to SEDS schema Red book (876x0 )

		To try and reduce the likelihood of multiple rounds of
rework, I thought I'd share my plan for responding to your CESG review
comments. I'm new to the process of publishing CCSDS documents, so let
me know if there is anything that jumps out at you as likely to be
problematic.

		*         Various parts of section 1, and sections 2.1,
2.2 and 2.4, will be updated to be largely in common between the two
documents (i.e. 876x0 and 876x1)

		*         The diagram shown below will be included and
explained at the start of both documents to show the relation of the
scope of the concepts they cover.

		*         Section 2.5, 'principles of an Electronic Data
sheet', which currently attempts to provide a rather-too-brief overview
of the all the concepts covered in the schema, will be deleted as
redundant with:

		a.       The schema Green book, which explains
everything in more detail, with diagrams.

		b.      The terms defined in section 1.5

		c.       The body of the document (section 3).

		Within next 2 weeks I'll produce, and sent to you
directly, a version of the document with:

		*         all the above structural  changes

		*         all of your comments not made moot by  the
above addressed

		*         bitmap graphics replaced by vectors

		*         no new row to the document control table
(stays at 'current draft', date updates).

		Assuming you ok that update, I will move onto addressing
the points raised by Keith Scott and Tomaso de Cola. Once that's done,
the document should presumably be ready to go to the next stage.

		richard

		<image001.png>

		SCISYS UK Limited. Registered in England and Wales No.
4373530.

		Registered Office: Methuen Park, Chippenham, Wiltshire
SN14 0GB, UK.

		Before printing, please think about the environment.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sois-app/attachments/20150506/dc4853ea/attachment.html>