v3.0a RFC Draft Notes

This section contains an overview of the proposed changes for the next version of the Scholar Snapp Data Standard.

What's New in v3.0a? (Latest XSD)

This section outlines key updates and additions in the Snapp v3a RFC XSD.

Ambiguity Removed from Required Elements

The v2.0 XSD specification has a logical ambiguity in many required elements: the specification allows required strings to be of zero length, meaning that the value can actually be null.

This issue tripped up field implementations (which expect "required" values to be non-null), including the Snapp UI itself (which was developed to require a non-zero-length string in "required" string fields).

Change Detail

The proposed v3.0 XSD will add a minLength=1 restriction to the ShortString and LongString types (lines 7 and 16 in the following snippet):

...
<xs:simpleType name="ShortString">	
	<xs:annotation> 			
		<xs:documentation>String used for short text fields</xs:documentation>
	</xs:annotation>
	<xs:restriction base="xs:string">
		<xs:minLength value="1"/>
		<xs:maxLength value="100"/>
	</xs:restriction>
</xs:simpleType>
<xs:simpleType name="LongString">
	<xs:annotation>
		<xs:documentation>String used for long text fields, such as essays</xs:documentation>
	</xs:annotation>
	<xs:restriction base="xs:string">
		<xs:minLength value="1"/>	
		<xs:maxLength value="4000"/>
	</xs:restriction>
</xs:simpleType>
...

The ShortString and LongString types are used as a base class for most string values in the standard. This change will force all elements that are present to have a non-zero-length string as a value.

The following snippet illustrates the practical effect of the change in XML data files:

...
<!-- Valid in v2.0, will not validate in v3.0 -->
<sds:FirstName></sds:FirstName>
...

The example above will not validate in v3.0 because FirstName is required, but doesn't meet the minimum length requirement.

References

• View ticket in the Scholar Snapp Data Standard JIRA Site (SSDS-1)
• See this change in GitHub (88e9a97)