[MOIMS-NAV-EXEC] [CCSDS] Action 32

Fran Martínez Fadrique fmartinez at gmv.com
Sun Jun 24 09:31:00 UTC 2018 

The XML --> KVN XSL transformation for the NEM was missing in the previous e-mail.

From: Fran Martínez Fadrique
Sent: domingo, 24 de junio de 2018 11:29
To: moims-nav-exec at mailman.ccsds.org
Subject: RE: [CCSDS] Action 32

Dear all,
Following on my previous e-mail and the comments during the last telecom, please find attached some additional material. Namely:

-          An installer (()NEMUserGenerationInstaller.zip) for the mock-up of a tool that can handle the XML file where the user defines the events to be supported with the associated parameters.

o   Uncompress the zip and install the .msi. It is in zip to prevent that your firewalls strip off the installer from the e-mail.

o   The tool is very simple and according to usual MS-Windows applications so it should be reasonable straight forward to use. Usual functions to open, close, save, exit, etc. are as commonly found in applications. I have created it for my commodity but I thought it would be good to share it with the group.

o   The data is represented in the tool as a tree where the high level nodes are the events and the second level nodes the parameters (see figure below)

o   The tree has a context menu where it is possible to add, delete, rename, duplicate and move nodes around (some functions are also duplicated in the menu bars)

o   Details are edited in the right most panel where the information appear when a node from the tree is selected.

o   Saving the file generates a .unem file. This extension is associated to the application such that you can open it by double-clicking in the file in your windows file explorer. These are the user files that can be open, edit, save, ... to further work on the user event definition prior to the generation of the schema file.

o   The small square icon [cid:image001.png at 01D40BAE.D2E205B0]  generates the schema file for the events defined in the tree.

o   The help menu contains a built-in sample file that can be loaded in an initial step if you have no other user generated file.

o   Disclaimer:

§  This is just a prototype so expect it to fail in some cases. Essentially no other testing that my use to produce it has been done.

§  Only for windows. I have generated it in windows 10. Porting to Linux should be possible but I have not tried yet.

§  There are some unexplained functions in the context menus that are mainly for my use; feel free to use them but I cannot guarantee the precise behaviour :(

§  Sorry but no help or tutorial yet. This will depend whether there is an actual use of the tool for the future.



-          An event file In XML (MOF_NEM_GEOEV_MTI1_20180623121200_20161124000000_20161209000000.xml) from another project (EUMETSAT's MTG) converted in the representation of the NEM that we have defined so far (actually what I selfishly :) have created from the definitions agreed with Colin and the inheritance of already existing NDM messages, mainly TDM). This is essentially the same as I provided in the previous e-mail but this time populated with some more realistic data. This can be probably reused later in the prototyping phase.

Obviously this one does not conform to the naming of events provided by Alain as its design has been completely decoupled from any NAV-WG definitions so far.



-          A representation of the previous XML file in KVN (MOF_NEM_GEOEV_MTI1_20180623121200_20161124000000_20161209000000.kvn). Again just a possible view based on my selfish approach, that I mention during the last telecom that I had half way through. A couple of remarks:

o   The structure is as any other NDM message.

o   I have kept the METADATA_START/STOP and DATA_START/STOP

o   I have used a similar structure for the main event record

§  EVENT = <epoch|event_id> [<offset>] <event_name>

·         The record can be parsed unambiguously

o   <epoch|event_id>: epoch starts with a number and if event_id is defined as xsd:ID it will start with a letter

o   <offset> is a numeric value and it is optional

o   If we assume that event_name starts with a letter, then it is always possible to identify the presence of <offset>

·         If <offset> is present the epoch representation is relative (to the event_id or the absolute epoch given); it is absolute otherwise

·         No support for the time scales in this version; that level of complexity requires additional thoughts

§  Parameters: there are essentially two types although all of them are treated seamlessly in the KVN approach

·         Defined by the design for all events: latestOffsetTime, earliestOffsetTime, user, ... These simply appear after the event. We'll have to decide which ones are mandatory to make this consistent with the XML version and to define the required order if any.

·         Defined by the user for each specific event: these also appear after the event and after the common parameters. Each one defined as needed and consistent with the XML representation

o   The KVN is generated with the same XSL transformation (with some extension for NEM) as we have already used in the past for the other messages. So it should be consistent in the handling when generating KVN from XML. Details will evolve as we evolve the KVN design.

o   The EVENT = is meant as separator between subsequent events in the list. I am not assuming that empty lines or COMMENT lines (there are none in this example) are used to separate event blocks or any other kind of information. Using EVENT = as separator I think is more consistent with previous KVN messages than trying to use some sort of EVENT_START/STOP tagging for every single event. Empty lines for the moment are for user reading convenience but may be removed in automatic XM-->KVN automated generation.



-          The user file (NEM_From_MTG_20180622.unem) that can be loaded in the tool that is compatible with the XML representation of the MTG file described above. I created this to illustrate this more representative example and also because I needed to create the XML schema file (NEM_From_MTG_20180622.xsd). I have also added the supporting NDM schemas with two remark:

o   They are edited to support just the NEM (commented out all other messages) to avoid having to move around the complete NDM collection

o   The namespace file has to be modified to import the specific schema file that defines the NEM. This will have to discuss because incorporates a modification to our NDM structure that complicates a bit its use.

As mentioned, all this subject to welcome comments and debate during the next telecons and meetings. All this will have to match with Alain's definitions and design in the other thread.

Best regards,
Fran

[cid:image002.jpg at 01D40BAE.D2E205B0]


From: Fran Martínez Fadrique
Sent: lunes, 11 de junio de 2018 19:15
To: moims-nav-exec at mailman.ccsds.org<mailto:moims-nav-exec at mailman.ccsds.org>
Subject: [CCSDS] Action 32

Hi All:
Regarding action 32: Define schema that can be used with an XML editor to define events and parameters that go with it to validate the event description.

Find attached the following files:

-          NEM_Test_20180610.xml: contains the XML file that is meant for users to define the collection of events at high level.

This has the following repetitive structure (I have used ascending node as example) to be generated easily with an XML editor. This is the seed for the generation of the corresponding XML schema to validate the final evnets file consistently with the definitions (fo events and parameters) discussed with the CSS group (Colin Haddow et al.)
        <event type="ASCENDING_NODE">
            <annotation>Date when the satellite is at the ascending node of the orbit (defined by ascending through ITRF equator)</annotation>
            <parameters>
                <parameter name="longitude" type="ndm:longitudeType" mandatory="false">
                    <annotation>Longitude at the time of the event</annotation>
                </parameter>
            </parameters>
        </event>

The fields <annotation> are optional

The block <parameters> is optional (either not present or empty) for events with no parameters

-          NEMUserDefinitionFile.xsd: is the XML schema that validates the previous file. It should be used to validate the user generated file (previous one) prior to attempt the generation of the final events file schema.

-          NEMDefinitions.xsd: has the basic definitions for the implementation of events. Essentially the event and epoch abstract types as defined

-          NEMUserDefinitionFile.xsl: implements the XSL transformation (XSLT) that generates the XML schema file that validates the actual NEM files from NEM_Test_20180610.xml. To test the generation:

o   Use an XML editor like XMLSpy or Oxygen (there may be other, even free, but I have not investigated) to load the NEM_Test_20180610.xml and apply the XSL transformation using NEMUserDefinitionFile.xsl. This will deliver the corresponding XML schema that should be very similar to NEM_Test_20180610.xsd

o   Use Xalan (in a linux console). Put the files in a folder and exert the command:

xalan -in NEM_Test_20180610.xml -xsl NEMUserDefinitionFile.xsl -out test.xsd -indent 2

this should generate a file test.xsd almost identical to NEM_Test_20180610.xsd

-          NEM_Test_20180610.xsd: the XML schema for the validation of the events file created from the NEM_Test_20180610.xml and the XSL transformation in NEMUserDefinitionFile.xsd

-          instance1.xml: This is an example of an events file. Just load it in an XML editor or a web browser like IE to verify its validity. The XML schemas NEM_Test_20180610.xsd (and all other .xsd files) should be in the same folder as instance1.xml

-          ndmxml*.xsd: supporting files to include the schema in the NAVGS workspace and to reuse existing basic defined types.

The basic operation sequences:

-          Create an events user definitions file similar to NEM_Test_20180610.xml

-          Apply the XSL transformation (e.g. with xalan); this generates the actual events XML schema

-          Create an events file similar to instance1.xml

-          Validate the events file with the generated XML schema

The file that closes the actions is essentially NEMUserDefinitionFile.xsd that is complemented with NEMUserDefinitionFile.xsl to generate the final XML schema.
The implementation should be compatible with the principles discussed with CSS although the XML is different as we already saw at the spring meeting in Gaithersburg. This may be a point of discussion with CSS in the next meeting but we are probably one step ahead of them in the actual implementation. We still need to define the list of proposed event acronyms if this is the path to follow.

Best regards,
Fran


P Please consider the environment before printing this e-mail.

______________________
This message including any attachments may contain confidential 
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.

______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la 
Informacion siendo para uso exclusivo del destinatario, quedando 
prohibida su divulgacion copia o distribucion a terceros sin la 
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje 
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado. 
Gracias por su colaboracion.

______________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-nav-exec/attachments/20180624/7ce3a714/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3132 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/moims-nav-exec/attachments/20180624/7ce3a714/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 35304 bytes
Desc: image002.jpg
URL: <http://mailman.ccsds.org/pipermail/moims-nav-exec/attachments/20180624/7ce3a714/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ndmxml-2.2_kvn.xsl
Type: text/xml
Size: 5462 bytes
Desc: ndmxml-2.2_kvn.xsl
URL: <http://mailman.ccsds.org/pipermail/moims-nav-exec/attachments/20180624/7ce3a714/attachment.xml>

More information about the MOIMS-NAV-EXEC mailing list