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

Fri Nov 13 13:26:00 UTC 2015

Hi John,

Thanks for taking the time to read through the mods to the SANA YB.  Since you covered a lot of ground I’ll just enter my replies into your notes.

Cheers, Peter

From: John Garrett <garrett at his.com<mailto:garrett at his.com>>
Date: Wednesday, November 11, 2015 at 5:59 PM
To: Peter Shames <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.

We have had a chronic issue in the XSG with people doing what you just did, saying “I have a conflict” or “I can’t be there.”  There is, in essence, no resource to do the work and that is why I want to merge this into the SAWG where we should have at least some assigned resource.  There will still be the possibility of others to “watch” what happens.

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.

I can provide the “track changes” versions.  The one for SANA YB is attached.  The other two docs are new.

Now for some comments on updated draft

Page ii – Delete. This is a extra Forward page

Sure

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.

What is usual is some minor statement of changes.  Some docs also use change bars.

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.

This will use whatever Gannett defines as the standard approach.  And in some docs the defintions are ordered to make sense based on relationships and precedence intead of just doing an alpha sort.

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?

These YB’s are normative on CCSDS, but not on the users, hence not BB.  That is aligned with the CCSDS Org & Proc doc.

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.

The WG’s do specify what they want.  The SANA opertor does do the implementation.  But not all WG really understand registries so some really weird stuff has been proposed and in some cases the WG thought they needed a registry where that made no sense.  After discussions with the SANA operator about what really has happened across all WG this formulation was arrived at.

The CESG does have the power to make exceptions and change outcomes, that is always its perogative.  But one of the reasons why we think these changes, and the RMP, are needed is that WG’s, without guidance and adequate oversight, have created chaos.  This is all intended to remedy that and to put in place a better process for the future to avoid such problems.

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.

These changes were all reviewed and discussed with the SANA Operator, the CCSDS Editor, and the Secretariat.  Theu are all in agreement and the initial feedback from the CESG was also positive.  The reason for this specific change is to change the published book from the “this is what the SANA must do to make a registry” to the more useful “this is what the registry is.”    This change in approach was requested by Gannett and concurred by the SSG.

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.

Right now we have no rules and we have chaos as a result.  The “wild west” approach have been shown not to work.  Given the proposed registries any WG that needs to use an organization or contacts registry entry will probably not need to do much at all to identify how to do this.  We have drafted a five page “cookbook” for the WG that provides a simple process to follow.  The SSG believes that this will be acceptable and ultimately much better than the current approach.

Section 3.10 – SANA now exists.  Should probably remove text referring to creation of SANA.

There are some new registries that could be recorded here.  I would prefer to do that, but agree that this will be overcome in time.

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.

Orange Books really have no standing as CCSDS documents.  This was, in fact, just discussed again in the CESG and confirmed.  The rationale is to not have experimental standards use limited resources.  That said, there may be instances where this is justified and there is always the possibility of a WG requesting a waiver from the SSG.

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.

These organization and contacts registries were, in point of fact, derived from the existing SCID and MACAO registries, with needed extensions.  There are already candidate registries and once this approach is approved we expect the published ones to be available in 2-3 months.  There needs to be a requirement for WG to use these registries or chaos will persist.  The SSG agreed approach is to adopt a transition approach where WG are intended to migrate to the new registries when they review the document, if not before.  These changes tend to be at the ‘corriegendum’ or Pink Sheet level.  Review and management of this is an SSG responsibility.

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.

To be reviewed.  This may be suitable to be eliminated unless we wish to record the new registries that are still to be developed.

>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.

That requirement is on Blue and Magenta Books that create registries.  This document does not create and registries, it specifies the registries structure and processes as a whole.

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/20151113/8d04fa58/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 313x0y11_working_markup-v1.doc
Type: application/msword
Size: 165376 bytes
Desc: 313x0y11_working_markup-v1.doc
URL: <http://mailman.ccsds.org/pipermail/sea-xsg/attachments/20151113/8d04fa58/attachment.doc>