[Moims-dai] OAIS-IF Document Tree

kearneysolutions at gmail.com kearneysolutions at gmail.com
Sat Dec 26 17:03:07 UTC 2020


Update to the document tree, based on side discussions.  

 

Adapters are non specific (Adapter 1, Adapter 2,  Adapter n) vs. specific
(Science, Telemetry, Documents, etc.).  Not sure if that's a good idea.
warrants discussion in the telecon.   That paragraph describing adapters is
on this slide for discussion, but of course it's too much to normally have
in a document tree figure.  Rather in informative material of a document.
It serves to explain that *some adapter(s) is(are) required as specified for
any given archive, but not necessarily the adapters shown in our prior
figures (science, telemetry, documents, etc.)  

 

Not sure if EAST/DEDSL/PVL/XFDU are "wired" to PAIS/CAIS, or directly to the
ADD, hence they are shows as "cloudy."  Some higher level document needs to
call them into existence, and allocate functionality to them.  Another topic
for telecon discussion.  

 

   -=- Mike

 

Mike Kearney

Huntsville, Alabama, USA 

 

From: kearneysolutions at gmail.com <kearneysolutions at gmail.com> 
Sent: Saturday, December 26, 2020 10:49 AM
To: 'MOIMS-Data Archive Interoperability' <moims-dai at mailman.ccsds.org>
Subject: RE: [Moims-dai] OAIS-IF Document Tree

 

I've been having side discussions with other folks on document colors, so I
thought I'd expand my first paragraph immediately below with CCSDS
background, as I understand it.  

 

People all over CCSDS have problems with book colors, so we're not alone.
But it seems fairly simple to me.  

 

The first principle is that we don't mix requirements types.  The three
types are:

*	Informative (not normative)  (which is then designated as green)
*	Normative but not testable specifications (which is then designated
as magenta)
*	Normative and testable (which is then designated as blue)

 

The CCSDS "founding fathers" seemed to think that it was really important
for a project manager to know which documents he can slap on a contract and
use with no further effort on his part (blue) and which documents will
require additional systems engineering effort by his project (magenta).  And
which documents are simply rationale (green) to justify/explain the blue and
magenta specs.  So their rules are to carefully separate these types of
requirements/statements into separate documents.  (In reality, the "options"
factor will require some systems engineering for all standards adoption, but
not as much for blue as for others.)  The "founding fathers" believed that
rigorous blue books are the primary reason for the success of CCSDS to date.


 

Working groups should *not* first write a book and then try to figure out
what color it is.  In that case, they will end up with mixed colors in one
book, and then everyone kills time (and sews discontent) arguing about what
color it should be.  Working groups should decide on a document tree and
provide pigeonholes where they can stuff informative, normative-non-testable
and normative-testable statements.  

 

That's it.  That's why I proposed a document tree.  Hope that background
helps.  

 

   -=- Mike

 

Mike Kearney

Huntsville, Alabama, USA 

 

From: kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com>
<kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com> > 
Sent: Wednesday, December 16, 2020 10:41 AM
To: 'MOIMS-Data Archive Interoperability' <moims-dai at mailman.ccsds.org>
Subject: RE: [Moims-dai] OAIS-IF Document Tree

 

Roger that on the magenta book.  That's how I painted it in the document
tree.  However, I think it's more important to decide whether we're going to
have a normative/testable/implementable document or not, and then decide
whether it's green, magenta or blue.  We decide what we need, and that
determines the color.  I think Steve is still figuring that out.  

 

By the interfaces on the bottom, I think you mean to move the
bindings/adapters under the AAL, right?  I considered that, but
traditionally an architecture "umbrella" type document specifies the
interaction between components, like interactions between the user
interfaces and the abstraction layer, and the interactions between the
abstraction layer and the bindings.  Hence it constrains both AAL and
bindings/adapters equally, so both AAL and bindings/adapters "report to" the
Architecture document.  Or their interfaces (UserIF<---->AAL, and
AAL<---->bindings/adapters) are specified by the Architecture document.
However, if you really think the interfaces between the AAL and the
bindings/adapters, as well as the functioning of the bindings/adapters will
all be specified in the AAL, we can move them under the AAL.  But I would
think the user interfaces (PAIS/PAIP/CAIS/CAIP) would equally be specified
by the AAL, so then we're moving everything under the AAL.  That doesn't
seem like a good document tree to me.  It doesn't look like a functional
decomposition process, as a normal project would see.  

 

However, we can talk about it more.  If the consensus is that everything
should be moved under the AAL, we can do that.  

 

   -=- Mike

 

Mike Kearney

Huntsville, Alabama, USA 

 

From: MOIMS-DAI <moims-dai-bounces at mailman.ccsds.org
<mailto:moims-dai-bounces at mailman.ccsds.org> > On Behalf Of garrett at his.com
<mailto:garrett at his.com> 
Sent: Wednesday, December 16, 2020 12:59 AM
To: 'MOIMS-Data Archive Interoperability' <moims-dai at mailman.ccsds.org
<mailto:moims-dai at mailman.ccsds.org> >
Subject: Re: [Moims-dai] OAIS-IF Document Tree

 

Hi Mike,

 

Thanks.


Before I start, I will mention that our CCSDS Project is currently expected
to generate a Magenta architecture book.

 

I think your first slide is pretty good, except I would put most of the
interfaces on the bottom, right side  items should appear under the Archive
Abstract Layer.  I also think there will be some direct implementations of
AAL for example a Java or Python implementation.  Thinking about it, there
could also be some database implementation works also.

 

May there be peace in your life,

-JOhn 

 

From: MOIMS-DAI <moims-dai-bounces at mailman.ccsds.org
<mailto:moims-dai-bounces at mailman.ccsds.org> > On Behalf Of
kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com> 
Sent: Tuesday, December 15, 2020 5:23 PM
To: 'MOIMS-Data Archive Interoperability' <moims-dai at mailman.ccsds.org
<mailto:moims-dai at mailman.ccsds.org> >
Subject: [Moims-dai] OAIS-IF Document Tree

 

Today's telecon had a soul-searching discussion of what an ADD (Architecture
Description Document) is, and what the Blue book that we're currently
developing is.  Steve described it's tendency towards focusing on the
details of the Archive Abstraction Layer, and hence we began to discuss
whether the content currently in the blue book is really ADD material or AAL
Blue Book material.  This led to a discussion where I said we should have a
document tree, so naturally I got the action to build it.  

 

Attached is a PPT with a first notional cut at a document tree.  I'll also
suggest that a Doc Tree figure should actually be in the ADD, or even
perhaps the OAIS Reference Model document (next revision, of course).  This
ADD after all, is intended to be the ADD for the OAIS-IF, not an overall
OAIS architecture.  The OAIS-IF ADD is subordinate to the OAIS RM, not the
other way around.  I did not try to include the shadow-organization of an
ISO Doc Tree.  To be complete we should probably do that, and spell out
acronyms.  Right now I consider this a working document for us insiders.  

 

A few comments are in the notes of the PPT charts.  Two additional charts
from IPELTU and our CMC material are added for reference.  

 

Some background on ADDs:  There is only one other in CCSDS, for Cross
Support, the CCSS-ADD, and it is here:

https://public.ccsds.org/Pubs/901x0g1.pdf

It is a green (informative, not normative) book, and it has a companion
Magenta book (an ARD - Architecture Requirements Document).  The ARD is not
in our plan.  We could conceivably have a magenta ADD that includes
normative requirements like an ARD.  

 

Some notable statements from the CCSS-ADD (relating them to our OAIS-IF
ADD):  

*	The foreword on page ii says:  The architecture described in this
document was developed based on the Cross Support Reference Model."  Our
counterpart statement is that our ADD is based on the OAIS Reference Model.

*	Section 2.1, page 2-1:  "The SCCS communications architecture
reference model described in this document establishes a common framework
that provides a basis for developing, providing, and using space
communications cross support services."  Our ADD does the same for Archive
Services.  
*	Section 2.2, page 2-1:  "This SCCS-ADD Green Book provides the
top-level description of the architecture elements of space communications
cross support."  Our ADD should provide the top-level description of the
architecture elements of the OAIS-IF.  Seems to me that "Top Level" includes
the entire UML chart that Steve has developed.  However, Steve made verbal
reference to focusing on the "gray/green boxes".  The document that focuses
on the abstraction layer should be the Archive Abstraction Layer Blue Book.
Our counterpart to the MAL <https://public.ccsds.org/Pubs/521x0b2e1.pdf> .  

 

So there's my notional Doc Tree, and how the ADD relates to it.  

 

   -=- Mike

 

Mike Kearney

Huntsville, Alabama, USA 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20201226/33e09e83/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OAIS-IF Document Tree.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 1016185 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20201226/33e09e83/attachment-0001.pptx>


More information about the MOIMS-DAI mailing list