Issue 14484: Use of the include conditions (xtce-rtf) Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov) Nature: Uncategorized Issue Severity: Summary: Description Ludovic FAURE 2007-10-31 17:22:31 GMT The CNES recommendations suggest a way to define packets descriptions without using inheritance. Actually, we define a unique generical packet (non-abstract container) that contains the definition of all the packets for a given mission. It is possible by using optional container and parameter entries, thanks to the element IncludeCondition. This approach is equivalent to the inheritance approach (a XSLT translator has been developped) and is simpliest to handle at the software level. What about write this approach in the magenta book as OK approach? Resolution: Revised Text: Actions taken: October 6, 2009: received issue Discussion: This is a sample of the MB example, following our recommendations: <xtce:ContainerSet> <xtce:SequenceContainer name="TMFrame" shortDescription="CCSDS TM Frame" abstract="false"> <xtce:EntryList> <xtce:ContainerRefEntry containerRef="AbstractTMFrameHeader"/> <xtce:ContainerRefEntry containerRef="AbstractTMPacket"/> <xtce:ContainerRefEntry containerRef="AbstractTMFrameTail"/> </xtce:EntryList> </xtce:SequenceContainer> <xtce:SequenceContainer name="AbstractTMFrameTail" shortDescription="" abstract="true"> <xtce:EntryList> <xtce:ParameterRefEntry parameterRef="CCSDS_TF_OC"/> <xtce:ParameterRefEntry parameterRef="CCSDS_TF_EC"/> </xtce:EntryList> </xtce:SequenceContainer> <xtce:SequenceContainer name="AbstractTMFrameHeader" shortDescription="" abstract="true"> <xtce:EntryList> <xtce:ParameterRefEntry parameterRef="CCSDS_FVERSION"/> <xtce:ParameterRefEntry parameterRef="CCSDS_SC_ID"/> <xtce:ParameterRefEntry parameterRef="CCSDS_TF_VC"/> <xtce:ParameterRefEntry parameterRef="CCSDS_OP_CTRL"/> <xtce:ParameterRefEntry parameterRef="CCSDS_MS_CNT"/> <xtce:ParameterRefEntry parameterRef="CCSDS_VC_CNT"/> <xtce:ParameterRefEntry parameterRef="CCSDS_TF_SECH"/> <xtce:ParameterRefEntry parameterRef="CCSDS_TF_SYNC"/> <xtce:ParameterRefEntry parameterRef="CCSDS_TF_ORDER"/> <xtce:ParameterRefEntry parameterRef="CCSDS_TF_SEGM"/> <xtce:ParameterRefEntry parameterRef="CCSDS_TF_FH"/> <xtce:ParameterRefEntry parameterRef="CCSDS_TF_HV"/> <xtce:ParameterRefEntry parameterRef="CCSDS_TF_HL"/> </xtce:EntryList> </xtce:SequenceContainer> <xtce:SequenceContainer name="AbstractTMPacket" shortDescription="" abstract="true"> <xtce:EntryList> <xtce:ParameterRefEntry parameterRef="CCSDS_VERSION"/> <xtce:ParameterRefEntry parameterRef="CCSDS_TYPE"/> <xtce:ParameterRefEntry parameterRef="CCSDS_SEC_HD"/> <xtce:ParameterRefEntry parameterRef="CCSDS_APID"/> <xtce:ParameterRefEntry parameterRef="CCSDS_GP_FLAGS"/> <xtce:ParameterRefEntry parameterRef="CCSDS_SSC"/> <xtce:ParameterRefEntry parameterRef="CCSDS_PLENGTH"/> <xtce:ContainerRefEntry containerRef="ComboPacket"> <xtce:IncludeCondition> <xtce:BooleanExpression> <xtce:ANDedConditions> <xtce:Condition> <xtce:ParameterInstanceRef parameterRef="CCSDS_VERSION"/> <xtce:ComparisonOperator>==</xtce:ComparisonOperator> <xtce:Value>0</xtce:Value> </xtce:Condition> <xtce:Condition> <xtce:ParameterInstanceRef parameterRef="CCSDS_TYPE"/> <xtce:ComparisonOperator>==</xtce:ComparisonOperator> <xtce:Value>0</xtce:Value> </xtce:Condition> <xtce:Condition> <xtce:ParameterInstanceRef parameterRef="CCSDS_SEC_HD"/> <xtce:ComparisonOperator>==</xtce:ComparisonOperator> <xtce:Value>0</xtce:Value> </xtce:Condition> <xtce:Condition> <xtce:ParameterInstanceRef parameterRef="CCSDS_APID"/> <xtce:ComparisonOperator>==</xtce:ComparisonOperator> <xtce:Value>123</xtce:Value> </xtce:Condition> </xtce:ANDedConditions> </xtce:BooleanExpression> </xtce:IncludeCondition> </xtce:ContainerRefEntry> </xtce:EntryList> </xtce:SequenceContainer> <xtce:SequenceContainer name="ComboPacket" shortDescription="" abstract="true"> <xtce:EntryList> <xtce:ParameterRefEntry parameterRef="RST00006"/> <xtce:ParameterRefEntry parameterRef="RST01006"/> <xtce:ParameterRefEntry parameterRef="DHT10001"/> <xtce:ParameterRefEntry parameterRef="DHT10002"/> <xtce:ParameterRefEntry parameterRef="OST10040"/> <xtce:ParameterRefEntry parameterRef="AST10061"/> <xtce:ParameterRefEntry parameterRef="ASD00001"/> <xtce:ParameterRefEntry parameterRef="AST50225"/> <xtce:ParameterRefEntry parameterRef="MISC01"/> <xtce:ParameterRefEntry parameterRef="DST50556"/> <xtce:ParameterRefEntry parameterRef="DHT40000"/> <xtce:ParameterRefEntry parameterRef="DHT10005"/> </xtce:EntryList> </xtce:SequenceContainer> </xtce:ContainerSet> Comment 1 Kevin Rice 2007-10-31 20:37:23 GMT Although using the "inline" includeCondition approach was never part of the original ideas in XTCE, you are not the first person to use it in this manner. I think for me personally its purely a pragmatic issue. I haven't look at in detail to determine if there there is anything really horribly wrong with using IncludeCondition in this way -- but let's assume there isn't, then should we accept it and put in the Magenta Book? I would favor it if it simplified early adoption by folks because the inheritance mechanism is expensive to implement in a general manner, and the message is going to be a little more expensive than this... This is going to be true for folks that principally want to use XSLTs to implement XTCE on the code side of things, although in the long run they may find that they write code ... still if it allows for easier early adoption, to me this isn't a bad thing. I do know that some of the original early authors will likely be opposed... but maybe not. I think it deserves some study. Comment 2 Johannes Stamminger 2007-11-12 09:38:49 GMT IMO both constructs are needed: The inheritance by way of a BaseContainer is usefull for packet identification/specialization. E.g. the datastream is known to provide only CCSDS packets. Therefore in the XTCE instance the used generic CCSDS packet layout is designed. Now imagine e.g. the secondary header containing an id of the structure of the user data part of the packet (as used in COLUMBUS). Those packets now get modelled by extending the generic CCSDS packet with the RestrictionCriteria relaying on a specific id value in the secondary header field. The IncludeCondition is needed always e.g. when having a indication flag. E.g. the secondary header flag in the CCSSD primary header, the packet may arrive with or without the secondary header. Same for the checksum flag. There are many different time formats. Which is actually delivered in the packet may be indicated by use of one or more flags. This cannot be solved by way of inheritance as then one would need to model any combination of flag value. So I agree on the recommendations to avoid use of IncludeCondition for packet identification purposes - but IMHO there is need for this construct at least as described above. This should be documented in the MB, too. Comment 3 Ludovic FAURE 2007-11-13 16:03:03 GMT Johannes, do you think the inheritance used in your first example may be replaced by includeCondition? I think we can have the structure of the user data part that exist, in a basic packet, only if the secondary header id has a specific value. For me both approach are equivalent. Comment 4 Johannes Stamminger 2007-11-14 07:17:14 GMT Sorry Ludovic, but my answer is no. Technically it may be possible sometimes but neither from semantics nor from readability/usability I feel this to be a good idea. IMO it is the responsibility of the more concrete packet description to identify itself, not the generic one. Another point: the generic CCSDS packet description may be separated from the concrete ones even in a different document and might get referenced from there only. Then the generic description does not even know of all concrete packets extending itself. Comment 5 Ludovic FAURE 2007-11-14 08:48:17 GMT I think i understand your point of view. It is true that, in my TM description, concrete packets are not explicitly identified. In fact in CNES tools, we dont need this identification (for the moment) that is why we dont use inheritance. Tools are working on a data flow model that is consistent with some CCSDS format EAST, DEDSL, and soon XTCE. The model is made from paper description and in a natural way by using existence conditions (discriminants). People that make those description are not familiar with UML and OO, and because we dont need packet identification, we suggest to not use XTCE inheritance. This is only for TM part because for TC part we need this identification and we use MetaCommand to make it possible. I think our approach is not so incorrect, it is just a different vision that matches our needs in a simple manner. Anyway, our tools may need in the future to get informations about TM packet identification. For me the simplest way are message instead of container because it permits to separate containers part that is the data fields description and the semantic and identification of packets part (that we dont need yet at cnes). For me those are different description levels. Also, Messages are a solution to avoid inheritance for people that are not familiar with. What do you think of it? End of Annotations:===== s is issue # 14484 Use of the include conditions Description Ludovic FAURE 2007-10-31 17:22:31 GMT The CNES recommendations suggest a way to define packets descriptions without using inheritance. Actually, we define a unique generical packet (non-abstract container) that contains the definition of all the packets for a given mission. It is possible by using optional container and parameter entries, thanks to the element IncludeCondition. This approach is equivalent to the inheritance approach (a XSLT translator has been developped) and is simpliest to handle at the software level. What about write this approach in the magenta book as OK approach? This is a sample of the MB example, following our recommendations: == 0 == 0 == 0 == 123 Comment 1 Kevin Rice 2007-10-31 20:37:23 GMT Although using the "inline" includeCondition approach was never part of the original ideas in XTCE, you are not the first person to use it in this manner. I think for me personally its purely a pragmatic issue. I haven't look at in detail to determine if there there is anything really horribly wrong with using IncludeCondition in this way -- but let's assume there isn't, then should we accept it and put in the Magenta Book? I would favor it if it simplified early adoption by folks because the inheritance mechanism is expensive to implement in a general manner, and the message is going to be a little more expensive than this... This is going to be true for folks that principally want to use XSLTs to implement XTCE on the code side of things, although in the long run they may find that they write code ... still if it allows for easier early adoption, to me this isn't a bad thing. I do know that some of the original early authors will likely be opposed... but maybe not. I think it deserves some study. Comment 2 Johannes Stamminger 2007-11-12 09:38:49 GMT IMO both constructs are needed: The inheritance by way of a BaseContainer is usefull for packet identification/specialization. E.g. the datastream is known to provide only CCSDS packets. Therefore in the XTCE instance the used generic CCSDS packet layout is designed. Now imagine e.g. the secondary header containing an id of the structure of the user data part of the packet (as used in COLUMBUS). Those packets now get modelled by extending the generic CCSDS packet with the RestrictionCriteria relaying on a specific id value in the secondary header field. The IncludeCondition is needed always e.g. when having a indication flag. E.g. the secondary header flag in the CCSSD primary header, the packet may arrive with or without the secondary header. Same for the checksum flag. There are many different time formats. Which is actually delivered in the packet may be indicated by use of one or more flags. This cannot be solved by way of inheritance as then one would need to model any combination of flag value. So I agree on the recommendations to avoid use of IncludeCondition for packet identification purposes - but IMHO there is need for this construct at least as described above. This should be documented in the MB, too. Comment 3 Ludovic FAURE 2007-11-13 16:03:03 GMT Johannes, do you think the inheritance used in your first example may be replaced by includeCondition? I think we can have the structure of the user data part that exist, in a basic packet, only if the secondary header id has a specific value. For me both approach are equivalent. Comment 4 Johannes Stamminger 2007-11-14 07:17:14 GMT Sorry Ludovic, but my answer is no. Technically it may be possible sometimes but neither from semantics nor from readability/usability I feel this to be a good idea. IMO it is the responsibility of the more concrete packet description to identify itself, not the generic one. Another point: the generic CCSDS packet description may be separated from the concrete ones even in a different document and might get referenced from there only. Then the generic description does not even know of all concrete packets extending itself. Comment 5 Ludovic FAURE 2007-11-14 08:48:17 GMT I think i understand your point of view. It is true that, in my TM description, concrete packets are not explicitly identified. In fact in CNES tools, we dont need this identification (for the moment) that is why we dont use inheritance. Tools are working on a data flow model that is consistent with some CCSDS format EAST, DEDSL, and soon XTCE. The model is made from paper description and in a natural way by using existence conditions (discriminants). People that make those description are not familiar with UML and OO, and because we dont need packet identification, we suggest to not use XTCE inheritance. This is only for TM part because for TC part we need this identification and we use MetaCommand to make it possible. I think our approach is not so incorrect, it is just a different vision that matches our needs in a simple manner. Anyway, our tools may need in the future to get informations about TM packet identification. For me the simplest way are message instead of container because it permits to separate containers part that is the data fields description and the semantic and identification of packets part (that we dont need yet at cnes). For me those are different description levels. Also, Messages are a solution to avoid inheritance for people that are not familiar with. What do you think of it?