[SEA-XSG] XML Standards and Guidelines (XSG) combined with SSG, Thursday, 12 Nov, Argentum room, 2.06, from 1430-1600

Thu Nov 12 19:39:15 UTC 2015

John,

What you described in your second paragraph is EXACTLY what is proposed.  And we'll leave the MACAO registries in place, as MACAO org.  You guys can adopt the common ones when you are ready.  We thinks that's probably a pink sheet change of a few lines of text unless you want to extract all the registry stuff and just point to our new one.

Peter

Sent from Peter's iPhone 6

Everything should be made as simple as possible,
but not simpler.

~Albert Einstein

On Nov 12, 2015, at 9:18 AM, John Garrett <garrett at his.com<mailto:garrett at his.com>> wrote:

Hi,

Took a very quick look at the other book and noticed that there were many mentions of MACAO and rules about them.  Also seems to be details of other registries.  I think this is a totally wrong approach.  This is sort of like Social Security trying to define requirements for taxes or health information systems because SSN is used for an identifier in those places.

I understood that SANA would be defining general registries such as (distributed) organization registry and person registry.  Then my MACAO BB could require that our users first register their organization in the SANA organization registry and get an ID affiliated with that registration.  Then my standard would specify how that organization ID fit into my needs for my registry.

From: sea-xsg-bounces at mailman.ccsds.org<mailto:sea-xsg-bounces at mailman.ccsds.org> [mailto:sea-xsg-bounces at mailman.ccsds.org] On Behalf Of John Garrett
Sent: Wednesday, November 11, 2015 8:59 PM
To: 'Shames, Peter M (312B)' <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>; 'SEA-XSG' <sea-xsg at mailman.ccsds.org<mailto:sea-xsg at mailman.ccsds.org>>
Subject: RE: [SEA-XSG] XML Standards and Guidelines (XSG) combined with SSG, Thursday, 12 Nov, Argentum room, 2.06, from 1430-1600

Hi Peter,

I don’t expect to make it to the meeting due to other scheduled meetings.  Also since we are just receiving these documents, I haven’t been able to provide a sufficient review.  I provide some comments now and will try to review it more once I return home.

First comment is in regards to inserting these items into the SAWG.  My personal preference would be that they two efforts be kept separate.  I think combining them will make scheduling to accommodate other meetings even harder and it will become even harder to contribute to either one.

A procedural comment to keep in mind for future updates is to show the updates.  That way I could have concentrated my review time to spend more time reviewing the updated sections.  By the way, is there a Word version of the current issue 1 SANA – Roles and Responsibilities available?  If so, I could possibly to a compare to get that info.

Now for some comments on updated draft

Page ii – Delete. This is a extra Forward page

Page iv – Document Control – Should status list updates made?  I think most books do so, but I’m not sure what is proper to do according to Pubs Manual.

Section 1.6 – conventions and definitions   - suggest name be changed.  Doesn’t seem to describe any conventions used in the book. Perhaps rename to Terminology as in other CCSDS documents. glossary has not been alphabetized.

Several places (e.g. Section 3.4 in Traceability bullet) talk about standards track documents – since these YBs are not standards track documents, but they are now creating and providing details of registries, different or additional wording may be needed.  Or should tht restriction be changed?

Section 3.6 – CESG relationship – I prefer the original version of this section.  Some problems with updates is I think WGs should be specifying what is needed in their books.  SANA operator should just be implementing what is requested not making a determination of what should be done.  I also think CESG should not have its options to decide things restricted as in the Note.  Perhaps that is the normal situation, but CESG should have power to make exceptions if they so desire.  Also I think notification of SANA should be automated part of submission to CESG for approval.  I also think that Red Book review should be able to go forward before SANA actually creates the registry.  As long as they have the info they need, it should be OK.  We don’t need another thing to slow down the process.

Section 3.8 – SANA Considerations – again I prefer the original and I do not like the updates.  Having different requirements for what is in draft documents and final documents will cause problems.  This will mean that extra efforts will be needed both by WG, by the CCSDS Editor, and by the SANA operator to ensure that correct changes are made between the draft document and the final document.
Also I’m not sure why user guidance is included in the SANA Considerations section.

Section 3.9 Second paragraph – change “protocol writers” to “document editors”.
Also I’m concerned that a whole new document of rules for a WG is being created.  There are already many requirements being inflicted on the WG.  I am concerned that if the policies cannot be included in this document, then perhaps there are too many or too complicated to actually use.

Section 3.10 – SANA now exists.  Should probably remove text referring to creation of SANA.
Why can’t an Orange Book specify a register?  I prefer the original where a CCSDS approved document can specify a registry. This was consistent in original document.  Proposed updates here are inconsistent with CCSDS approved documents mentioned in other sections.
Talk about re-use of registries should be general and not specific mentions of specific registries (especially ones that do not yet exist) should be here.
MACAO update will use SANA registries if they support the functionality required and if we continue to require those items in the MACAO registration.  As we’ve discussed, we will likely drop the need to register some of the items now required.  WG should decide whether to use SANA registries.  If WG decides not to use SANA registries, CESG should evaluate reasons and approve it or not.  Hopefully SANA registries will be implemented well and WGs will want to use them and not be forced to use something they feel doesn’t meet their needs.

Annex A: Eliminate.  This is incorrect since most of these are already SANA registries. There is no longer a need for  a list of candidate registries.  SANA already provides a list of registries that it supports.  This list is an excellent example of something that could be in a registry to prevent the need to update the document whenever a change is made to the list.

>From the quick review, I’m not sure if this document is requiring any registries.  If so, I think this document should take its own medicine and include an actual SANA Considerations section.

I’ll probably have more later, but it is late now.

Live, Laugh, Love, and Work for Peace,
-JOhn

From: sea-xsg-bounces at mailman.ccsds.org<mailto:sea-xsg-bounces at mailman.ccsds.org> [mailto:sea-xsg-bounces at mailman.ccsds.org] On Behalf Of Shames, Peter M (312B)
Sent: Tuesday, November 10, 2015 8:33 AM
To: SEA-XSG <sea-xsg at mailman.ccsds.org<mailto:sea-xsg at mailman.ccsds.org>>
Subject: [SEA-XSG] XML Standards and Guidelines (XSG) combined with SSG, Thursday, 12 Nov, Argentum room, 2.06, from 1430-1600

Dear XSG members,

We nominally have a SEA-XSG meeting scheduled for Thursday afternoon.   Because there is no ability in the scheduling system to indicate two different 1-2 hour meetings both the SANA Steering Group (SSG) and the XSG are shown as separate meetings and in their own meeting rooms.

For Thursday, 12 Nov, we will be holding a single joint meeting of the SSG and the XSG.  This will be in the Argentum room, 2.06, from 1430-1600.  I have to do the Boot Camp from 1330-1430 or I would have started earlier.   The focus of the agenda will primarily be the SANA re-engineering topics, relating to the proposed re-work of the SANA registries.  You are welcome to join us for this discussion.  The documents are attached.  You will see that the XML registries in the SANA are a topic of interest, so it may pay to attend.  See attached SANA documents (revised YB and new RMP) to see what is being proposed.

The primary XSG specific topic that I am aware of is that the CCSDS URN RFC has been aproved by the IETF and is now awaiting final tech editor processing.  This is extremely good news.  If there are other topics that should be addressed at this meeting please bring then up now.  If needed we will schedule a splinter session on Wed or Thursday to address them.

I think you should all be aware that we are proposing to wrap this XSG work into the SEA SAWG that is being re-started.   I do think that we will still need something like an XML expert group to coordinate changes to the XML registries, so the XSG in something like its present form and membership may persist.  Comments on all of this are welcome.

Thanks, Peter

From: Shames Peter <messenger at webex.com<mailto:messenger at webex.com>>
Reply-To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Date: Tuesday, November 10, 2015 at 5:01 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Subject: (Forward to others) WebEx meeting invitation: SANA Steering Group

You can forward this invitation to others.

Hello,

Shames Peter invites you to join this WebEx meeting.

SANA Steering Group

Thursday, November 12, 2015

2:30 pm  |  Europe Time (Berlin, GMT+01:00)  |  1 hr 30 mins

Join WebEx meeting<https://iso-meetings.webex.com/iso-meetings/j.php?MTID=m0119eb06bff29d68707e72c3db2ea1e2>

Meeting number:

959 231 422

Meeting password:

inSANA

Join by phone

0800-051-3810 Call-in toll-free number (UK)

+44-203-478-5289 Call-in toll number (UK)

Access code: 959 231 422

Global call-in numbers<https://iso-meetings.webex.com/iso-meetings/globalcallin.php?serviceType=MC&ED=363869527&tollFree=1>  |  Toll-free calling restrictions<http://www.webex.com/pdf/tollfree_restrictions.pdf>

Add this meeting<https://iso-meetings.webex.com/iso-meetings/j.php?MTID=mc9f4cceccda04ed22bc1a1ac3ad9d51f> to your calendar.

Can't join the meeting? Contact support.<https://iso-meetings.webex.com/iso-meetings/mc>

IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-xsg/attachments/20151112/75e5690f/attachment.html>