-
Notifications
You must be signed in to change notification settings - Fork 17
Proposal: Allow different datatypes on *ObjectPropertyTypes
Status: Closed
Comment Period Closes: 01/02/2014
Affects Backwards Compatibility: No
Relevant Issues:
https://github.com/CybOXProject/schemas/issues/3
https://github.com/CybOXProject/schemas/issues/112
Many fields within CybOX Object types use one of the several *ObjectPropertyTypes that correspond to datatypes within XML Schema (for example, StringObjectPropertyType, PositiveIntegerObjectPropertyType, Base64BinaryObjectPropertyType, etc.). These types currently have a fixed attribute indicating that the underlying XML data type cannot be changed. We have identified several scenarios where the underlying XML data type is not sufficient for the possible values in the field, even though it indicates the "desired" type for that field:
- The StringObjectPropertyType can only hold UTF-8-encoded characters, not arbitrary binary data, although in many cases software programs do not enforce this restriction [Issue #3].
- Many fields within the NetworkPacket object use "hexBinary" to indicate the way an integer is packed into the packet data, however it is semantically a numerical value. [Issue #112].
The current "fixed" attribute on all the *ObjectPropertyTypes should be changed to just a "default". This would allow using a different XML Schema datatype that is more appropriate or conducive for representing a particular value.
We should also update annotations in the objects to clarify that certain datatypes SHOULD or SHOULD not be used on various *ObjectPropertyTypes, as appropriate (for example, using an anyURI in place of a NonNegativeInteger is likely undesirable), even though these are not enforced by the schema itself.
Existing content and implementations will not be affected. When "datatype" is not explicitly provided, its (assumed) value will be unchanged from previous versions. However, future implementations will need to detect and handle cases when the "datatype" differs from its default value. As the datatype was formerly fixed, no additional processing was required.
- Are there any reasons why this change should not be made?
- Is there a better way to create the necessary flexibility in representing data types within CybOX?
- Does the additional processing requirement create unnecessary burden?