Issue 14486: relative path in the parameterRef (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:38:22 GMT In the first example of the chapter 2.3.3.1, the refernce to the parameter used the relative path: "PrimaryHeader.apid". The relative path for the space system tree uses '/' to separate space systems, why not use '/' to separate container from other container or parameter? By this way we will get an homogeneous way to define paths in XTCE. Resolution: Revised Text: Actions taken: September 17, 2009: received issue Discussion: Comment 1 Kevin Rice 2007-10-31 20:33:09 GMT I'm a little confused by the comment so let me clarify what XTCE currently says is ok within the specification -- and we can do from there. Right now XTCE says that any reference outside of the current spacesystem to another construct must use a "Path" to specify the location of the item being referenced. This would be true of Parameters, ParameterTypes, Containers, Streams ... anything that has a "Reference" someplace in the schema. (Actually the ANNOTATION says if its not found the name will be searched for in progressively higher spacesystems. And the Magenta Book says -- no in fact you MUST put the Path there... That's another story -- but in either case we can agree you MAY need to put Path info there to tell where the item is in document) But the way this works is the "path" portion only refers to the SpaceSystem TREE through the NAME attribute associated with each SpaceSystem element, and does not include any reserved names to specify exactly what portion of the schema the reference refers to... Instead that information is found from within the Reference itself, where it comes from and then depends on the concept as outlined in the "keys" at the beginning of the schema to sort out the exact location. For example XTCE does ALLOW this: /MySpaceSystem/MySpaceSubSystem/BatV1 But we don't know just from this Ref that this refers to a Parameter. Instead we depend on the location of the Ref to tell us what it should be -- maybe this is a parameterRef for example in the container area, so we would know it SHOULD be in ParameterSet -- but which ONE? In TelemetryMetaData or CommandMetaData? Well it COULD BE either -- in current XTCE, we allow either. What this means is WE DO NOT ALLOW THIS: /MySpaceSystem/MySpaceSubSystem/TelemetryMetaData/BatV1 Which would mean we have some reserved words in the path - of course this does not completely gives us all the information either -- as we would not know just by looking at the reference that BatV1 is in fact in ParameterSet. Along those lines we do NOT allow this: /MySpaceSystem/MySpaceSubSystem/TelemetryMetaData/ParameterSet/BatV1 So without that information in the Reference, we end up with strictly speaking forming a common "reference name space" in certain parts of the schema, and that is what the KEYS are supposed to help sort out. Does this clear anything up? Comment 2 Johannes Stamminger 2007-11-12 10:04:29 GMT IMHO there is a simple misunderstanding: the dot in "PrimaryHeader.type" is no path indication. It refers to the way of specifying the primary header as in the bottom of page 18, using an AggregateParameterType: the type is a Member of the AggregateParameterType named CCSDSHeaderType. For paths, regardless if pointing to other SpaceSystems, parameters or containers, the slash is to be used. BTW: is it allowed to write the affected parameterRef like "./PrimaryHeader.type", too? With the dot now pointing to the current "element" (*not* XML element but structural as described by KR in his comment before). It is stated in the MB that path refs are UNIX like but this is not explicitly mentioned. Comment 3 Kevin Rice 2007-11-12 15:23:19 GMT At the moment the spec essentially says the names in the "path" refer to spaceSystem names -- the attribute name in the spacesystem element. Thus a "./parameter" refer to the spaceSystem the parameter is defined in... did I answer the question? Comment 4 Johannes Stamminger 2007-11-12 15:28:29 GMT OK, I did not have a look to the spec for this, just to the MB. And there only relative paths using '..' are used. The (btw: double, once relative path, once Member of the referred type) meaning of '.' is not explained. Comment 5 Kevin Rice 2007-11-12 15:32:21 GMT Ok I'll put something in the MB about it. It's probably not explained really in the spec very precisely but may use the term "unix-like" paths. So the "." and ".." would be similar in function to directory style filesystem naming on unix/linux -- with caveat being everything is based on the SpaceSystem 'name' attribute until the last part which would be a parameter, container, metacommand, or metacommand/commandcontainer name, etc... End of Annotations:===== s is issue # 14486 relative path in the parameterRef Description Ludovic FAURE 2007-10-31 17:38:22 GMT In the first example of the chapter 2.3.3.1, the refernce to the parameter used the relative path: "PrimaryHeader.apid". The relative path for the space system tree uses '/' to separate space systems, why not use '/' to separate container from other container or parameter? By this way we will get an homogeneous way to define paths in XTCE. . . . . Comment 1 Kevin Rice 2007-10-31 20:33:09 GMT I'm a little confused by the comment so let me clarify what XTCE currently says is ok within the specification -- and we can do from there. Right now XTCE says that any reference outside of the current spacesystem to another construct must use a "Path" to specify the location of the item being referenced. This would be true of Parameters, ParameterTypes, Containers, Streams ... anything that has a "Reference" someplace in the schema. (Actually the ANNOTATION says if its not found the name will be searched for in progressively higher spacesystems. And the Magenta Book says -- no in fact you MUST put the Path there... That's another story -- but in either case we can agree you MAY need to put Path info there to tell where the item is in document) But the way this works is the "path" portion only refers to the SpaceSystem TREE through the NAME attribute associated with each SpaceSystem element, and does not include any reserved names to specify exactly what portion of the schema the reference refers to... Instead that information is found from within the Reference itself, where it comes from and then depends on the concept as outlined in the "keys" at the beginning of the schema to sort out the exact location. For example XTCE does ALLOW this: /MySpaceSystem/MySpaceSubSystem/BatV1 But we don't know just from this Ref that this refers to a Parameter. Instead we depend on the location of the Ref to tell us what it should be -- maybe this is a parameterRef for example in the container area, so we would know it SHOULD be in ParameterSet -- but which ONE? In TelemetryMetaData or CommandMetaData? Well it COULD BE either -- in current XTCE, we allow either. What this means is WE DO NOT ALLOW THIS: /MySpaceSystem/MySpaceSubSystem/TelemetryMetaData/BatV1 Which would mean we have some reserved words in the path - of course this does not completely gives us all the information either -- as we would not know just by looking at the reference that BatV1 is in fact in ParameterSet. Along those lines we do NOT allow this: /MySpaceSystem/MySpaceSubSystem/TelemetryMetaData/ParameterSet/BatV1 So without that information in the Reference, we end up with strictly speaking forming a common "reference name space" in certain parts of the schema, and that is what the KEYS are supposed to help sort out. Does this clear anything up? Comment 2 Johannes Stamminger 2007-11-12 10:04:29 GMT IMHO there is a simple misunderstanding: the dot in "PrimaryHeader.type" is no path indication. It refers to the way of specifying the primary header as in the bottom of page 18, using an AggregateParameterType: the type is a Member of the AggregateParameterType named CCSDSHeaderType. For paths, regardless if pointing to other SpaceSystems, parameters or containers, the slash is to be used. BTW: is it allowed to write the affected parameterRef like "./PrimaryHeader.type", too? With the dot now pointing to the current "element" (*not* XML element but structural as described by KR in his comment before). It is stated in the MB that path refs are UNIX like but this is not explicitly mentioned. Comment 3 Kevin Rice 2007-11-12 15:23:19 GMT At the moment the spec essentially says the names in the "path" refer to spaceSystem names -- the attribute name in the spacesystem element. Thus a "./parameter" refer to the spaceSystem the parameter is defined in... did I answer the question? Comment 4 Johannes Stamminger 2007-11-12 15:28:29 GMT OK, I did not have a look to the spec for this, just to the MB. And there only relative paths using '..' are used. The (btw: double, once relative path, once Member of the referred type) meaning of '.' is not explained. Comment 5 Kevin Rice 2007-11-12 15:32:21 GMT Ok I'll put something in the MB about it. It's probably not explained really in the spec very precisely but may use the term "unix-like" paths. So the "." and ".." would be similar in function to directory style filesystem naming on unix/linux -- with caveat being everything is based on the SpaceSystem 'name' attribute until the last part which would be a parameter, container, metacommand, or metacommand/commandcontainer name, etc...