XTCE13 — String Encoding Length descriptions needs further clean up

The current schema improves upon XTCE 1.1 but still has issues. Firstly it lacks overall clarity and simple syntax. Second it appears to give 2 ways to describe an overall "string box" and dynamic part which may be confusing to some (we should favor one over the other). See for example Fixed plus one of the TerminatingChar or LeadingSize, or Variable/DynamicValue and maxSizeInBits. Also maxSizeInBits is required and this may be a problem in some scenarios. Finally the choice of syntactic element does make it possible to say that variable length has a dynamic look up terminatingChar and LeadingSize.

The overall use cases of support are:

• fixed string
• fixed box, variable string
• variable string but overall max size (simlar to above)
• variable string unlimited

Here's a longer write up:

1) Fixed string, like as in literally:

StringDataEncoding/SizeInBits/Fixed/FixedValue

2) Fixed string BOX but variable inside that...

StringDataEncoding/SizeInBits/Fixed/FixedValue AND one of Fixed/LeadingSize or Fixed/TerminatingChar

3) Fixed string BOX but variable inside that... yeah we can say this two ways then:

StringDataEncoding/Variable/@maxSizeInBits=sizeOf(StringBox) AND one of DynamicValue or DiscreteValue to look up the length from it, and then optionally either LeadingSize or TerminationChar or both even too

This one is terribly confusing...

4) Variable and Max size

StringDataEncoding/Variable/Dynamic|Discrete plus required maxSizeInBits and then optionally either LeadingSize or TerminationChar too

5) Variable but no max size stated in source material

StringDataEncoding/Variable/Dynamic|Discrete set maxSizeInBits to ginormous and probably just ignore and then optionally either LeadingSize or TerminationChar too

So #1 and #2 make sense but are a tad unwieldy syntax wise... well we are probably a little stuck there in regard to "backwards compatibility". This is probably the most used, these two.

I think #4 makes sense – although mixing in the leading size or termination char seems either just plain confusing or weird...

#5 is unfortunate but making @maxSizeinBits optional seems quick fix OR the workaround isn't necessarily bad.

The "let's set everything" #3 isn't great but could be factored away in documentation