New vectorBaseTypes

[MarAlder]

Problem

In CPACS all vectors have the type stringVectorBaseType. This allows any kind of strings (e.g., comma seperated lists) and does not explicitly specify what to expect from such elements if not written in the documentation.

Possible Solution

I therefore propose to add new vectorBaseTypes which inherit from the stringVectorBaseType and further restrict the content.

doubleVectorBaseType

• restricts the stringVectorBaseType to the following pattern:

<xsd:pattern value="([-+]?(\d+)?.\d+(([eE][-+]?)?\d+)?|(NaN))(;(([-+]?(\d+)?.\d+(([eE][-+]?)?\d+)?)|(NaN)))*"/>

Example: (see example file for latest updates):

<doubleVectorTest>123.456;+1234.456;-1.2344e56;-.45E-6;3.2</doubleVectorTest>

intVectorBaseType

• restricts the stringVectorBaseType to the following pattern:

<xsd:pattern value="[-+]?\d+(;[-+]?\d+)*"/>

Example:

<intTest>1;2;-1;-2;0;1;2</intTest>

posIntVectorBaseType

• if needed as discussed in the loadCase definition for pointIDs in Revision of loadCases #637
• restricts the stringVectorBaseType to the following pattern:

<xsd:pattern value="\d+(;\d+)*"/>

Example:

<pointIDs>1;2;3;4;5;6</pointIDs>

Open questions & potential extensions

• does this negatively affect APIs and libraries such as TiXI, TiGL or other community software?
• did I forget test cases? In this case please add them as reply to this issue
• the attribute mapType seems superfluous and is set to optional so that old data sets are still valid (see Make tixiGetFloatVector independent of mapType attribute DLR-SC/tixi#143). Did I miss a certain reason to enforce this attribute?
• how do we proceed with the arrays? We could assign the same patterns where needed.
• patterns could be enabler for equation-based parametrization

[MarAlder]

In addition to the above list of new vectorBaseTypes:

uIDReferenceVectorBaseType

To be honest, we should try to avoid the use of such a type in CPACS and use an XML sequence of elements of type xs:IDREF as implemented in stringUIDBaseType instead , if possible (see #634 (comment)). However, if this is not possible because too many uID references would have to be specified (so that the XML sequence would be too long), we should at least introduce a uIDReferenceVectorBaseType.

As xs:IDREF is a restriction of 'xs:NCName' the following proposal allows the same pattern as xs:ID in addition with semicolon seperators. XML processors have no chance to check whether these uIDs really exist in the data set, but it will at least enforce valid ID patterns.

I want to call it uIDReferenceVectorBaseType (instead of maybe uIDVectorBaseType) to make clear that this is a list of referencing elements and must not be used to specify a list of uIDs.

<xsd:pattern value="([\i-[:]][\c-[:]]+)(;([\i-[:]][\c-[:]]+))*"/>

[MarAlder]

Added with a27d18b:

• trailing edge dot for float vector values
• e-notation for integer vector values

[MarAlder]

The new basic types seem to fulfill their purpose well. Must now be tested in practice.

[MarAlder]

For the sake of completeness: empty characters are added as valid characters to the new base-types via fa31cea.