performanceRequirements: required and optional flightPerformanceCases

[MarAlder]

In the current CPACS 3.3-beta proposal we have the definition of flightPerformanceCases along with a uID-Vector of required and optional flightPerformanceCases. Before implementing it in the RC there was the question whether we group the information of required and optional cases under flightPerformanceCases itself (following development guideline §3 on #704). Perhaps it is even easier to specify this via a dedicated usage element (open for naming proposals), which provides the options required and optional here.

• current state:
  

• proposal:
  

Using TiXI list of xpaths and uIDs could be generated by a simple XPath query, for example:

xpath_expression = '//*/flightPerformanceCases/flightPerformanceCase[usage="required"]'
xpaths = [tixi_h.xPathExpressionGetXPath(xpath_expression,i+1) 
          for i in range(tixi_h.xPathEvaluateNodeNumber(xpath_expression))] 
uIDs = [tixi_h.getTextAttribute(xpath,"uID") for xpath in xpaths]

maybe interesting for: @HHOPs, @ErwinMoerland, @sdeinert

[ErwinMoerland]

I am fully ok with the proposal, it indeed fits better to the naming convention and XPATH queries to filter between required and optional cases are not too cumbersome.

I suggest however to make the node optional. I assume a lot of times a complete set of required performanceCases will be provided, then the information seems superfluous.

[MarAlder]

the information seems superfluous

I also thought about making it optional, but then we need to decide what it means if the element is not given. Furthermore, the XPath query becomes a bit more complex as the user must implement the implicit " if element not given then required" assumption or so. I would argue that it is not superfluous but just explicit.

However, if it is the case in practice that a predominant part is always required, then we can also implement an optional <required>False</required> element of type boolean. Then the implicit assumption at this point might be fine.

[ErwinMoerland]

the information seems superfluous

I also thought about making it optional, but then we need to decide what it means if the element is not given. Furthermore, the XPath query becomes a bit more complex as the user must implement the implicit " if element not given then required" assumption or so. I would argue that it is not superfluous but just explicit.

@MarAlder: you're right, explicit is better than implicit. So better define the node explicitly indeed.

However, if it is the case in practice that a predominant part is always required, then we can also implement an optional <required>False</required> element of type boolean. Then the implicit assumption at this point might be fine.

Throwing in a thought: maybe we should define a general nomenclature for requirement classification. We could use the MoSCoW classification scheme (Must, Should, Could, Won't) for settings that have to do with requirements.

<reqClassification>must</reqClassification>
<reqClassification>should</reqClassification>
<reqClassification>could</reqClassification>
<reqClassification>wont</reqClassification>

Then trough toolspecific settings, a tool can be provided with the information on which cases to consider within the analysis.

P.S.: the won't setting at first seems unnessecary (then why not just drop the content). It might serve the purpose of keeping an overview of a complete set of requirements though..

[MarAlder]

Funny scheme - Fischer didn't teach this :). Why not. You think the difference between should and could is clear in this context? I can already see that my phone will not stop ringing with questions what exactly to choose :)

[MarAlder]

No counterarguments during the review period.