New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problematic start value attribute for arrays of strings #513

Open
pmai opened this Issue Dec 17, 2018 · 4 comments

Comments

Projects
None yet
5 participants
@pmai
Copy link
Collaborator

pmai commented Dec 17, 2018

The current schema extensions for the array FCP define all start attributes as XML Schema List types of the underlying primitive type. While this works for all other types, it is problematic for the string data type (as noted in discussions with the DCP project):

<xs:element name="String">
	<xs:complexType>
		<xs:attributeGroup ref="fmi3VariableCommonAttributes"/>
		<xs:attribute name="start">
			<xs:annotation>
				<xs:documentation>Value before initialization, if initial=exact or approx</xs:documentation>
			</xs:annotation>
			<xs:simpleType>
				<xs:list>
					<xs:simpleType>
						<xs:restriction base="xs:string"/>
					</xs:simpleType>
				</xs:list>
			</xs:simpleType>
		</xs:attribute>
	</xs:complexType>
</xs:element>

As defined, string start values can no longer contain whitespace, since the XML schema parsing will tokenize list types on any whitespace occurrence (see http://www.w3.org/TR/xmlschema11-2/#list-datatypes for details). This is a very restrictive change, which makes the string type more or less useless for many applications.

A work-around for this problem would be to place the start value into an element, with child elements for each array item. While this produces quite a bit of overhead, in the case of strings this is likely to be non-critical compared with the space already needed by the strings. For other types, especially the numeric types, it would be preferable not to go down this route, since the overhead in those cases would be prohibitive.

While this would lead to non-uniform syntax for the basic types, it seems the least bad solution for now.

Opinions?

@pmai pmai self-assigned this Dec 17, 2018

@pmai pmai added this to the FMI3.0 milestone Dec 17, 2018

@t-sommer

This comment has been minimized.

Copy link
Collaborator

t-sommer commented Dec 18, 2018

Using the format proposed in #514 the start values of a String variable could be stored as

<ModelVariables>
  <String name="filename" valueReference="1" description="Absolute path to the input file">
    <Value>/tmp/engine.mat</Value>
  </String>
</ModelVariables>
@APillekeit

This comment has been minimized.

Copy link
Collaborator

APillekeit commented Jan 4, 2019

We agree with the observation and suggestion of @pmai .

Based on our understanding of @pmai's suggestion:

  • For all variable types except for "String" (and maybe "Binary") we should stick to the list definition, for efficiency reasons.
  • For "String" (and maybe "Binary") we should require one child element for each start value in an array.

Example for possible String XML schema definition

    <xs:element name="String">
              <xs:complexType>
                    <xs:sequence maxOccurs="unbounded">
                          <xs:element name="Start">
                                 <xs:complexType>
                                         <xs:attribute name="value" type="xs:string"/>
                                  </xs:complexType>
                           </xs:element>
                    </xs:sequence>
                    <xs:attributeGroup ref="fmi3VariableCommonAttributes"/>
              </xs:complexType>
    </xs:element>

@pmai

This comment has been minimized.

Copy link
Collaborator

pmai commented Jan 11, 2019

Not sure, but the values could also be included as element content:

<xs:element name="String">
          <xs:complexType>
                <xs:sequence maxOccurs="unbounded">
                      <xs:element name="Start" type="xs:string"/>
                </xs:sequence>
                <xs:attributeGroup ref="fmi3VariableCommonAttributes"/>
          </xs:complexType>
</xs:element>
@chrbertsch

This comment has been minimized.

Copy link
Collaborator

chrbertsch commented Jan 11, 2019

Discussion in meeting on 11.2.2019
Klaus: Agree, that we have this problem. Shall we fix this only for strings, or for all data types
Pierre: not for all data types, for other types we do not have this problem. Binary does not contain spaces, but overhead would be small.
Pierre: Above there are two variants
Klaus: this would be the first time that we use the content and not as an attribute
Pierre: perhaps best to use an attribute
Andreas P.: I can ask Irina
Klaus: almost some filesize. One has to use certain quoting
Pierre: For quoting slightly better for the content than with attributes, but not important.
Pierre: shall we use this mechanism also for binaries?
Andreas J, Pierre: No preferences.
Andreas J: could we have for binaries two examples to see it?
Pierre: Yes, will post them

Pierre: Irina could do the change for strings as she preferres.
all: agree

@pmai pmai assigned IZacharias and unassigned pmai Jan 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment