Design Rationale

Design Choices

See this page for general implementation advice

Flexibility

• There are multiple ways to encode the same data into STIX Solution: implementations should handle a the full range of potential input and create well-formatted output

• STIX can be extended, meaning that incoming data may be in an unfamiliar format Solution: Users may communicate a Profile to negotiate the type of STIX format that they support and will produce

Versioning

see page

Data Markings

• We use a list of XPaths to mark specific elements, because of TODO
• As we move away from XPaths, we need to address these use-cases

• Ease of consuming the markings and keeping track of what is bound to what. The XPath is hard and confusing in XML and near impossible in other languages. If things are hard, even in XML, then the probability of people using it or writing code to do something with it will be low. We need flexibility but it needs to be easy to implement in code.
• Allow parsers to understand what marking is to be applied to an object, before the said object is read and processed
• Apply multiple markings to a single element.

Language Choice

• We use XML, because TODO

Implementation

• Rather than storing XML data in a persistent database, we suggest that developers parse STIX data and store it in their a database-specific manner. Python scripts along with database-specific queries may be used to export STIX content on demand.