| Has the group considered a naming convention that combines type and field name into a single term to avoid having separate items for key vs type?
For example:
“ipv4_address_s”: “12.1.1.1” “ipv4_address_ui”: 2323232 “a_integerfield_i”: 12 “a_unsignedint_ui”: 5 “a_hexfield_h”: “0f020f03”, “a_hash_md5_h”: 0dd3f6a83347768b88f3013dce592d3d “a_hash_sha512_h”: “5f199ae2df70ec1d73c9c43ece12350d9b50dab7c043264fee6ab4566be81a5c3b52328e006a9c90faba06f763b382ee5a48d6cff2867a9aeb95e01fe4c446ee"
The general layout would be "<field_key>_<type_identifier>” : <value>
where type_identifier is predefined and known for all types that are supported.
It would include strings, integers, hex, mac-addresses, floats….etc.
This has the advantage of efficiently defining fields and allow reading of the data without knowing a-priori the types. It allows new fields to be easily introduced by providers without having to agree a pre-defined schema.
Allan
>I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name. My preference would be to keep our current structure for naming but use a different >formatting rule for type names, field names, and string literals.
+1
If we pick one, we shouldn’t use dashes, which are not valid characters in many programming language variables (hence why field names are underscores).
I would actually like to distinguish them more, to be honest, at least in the spec. As it is, it’s very hard to tell the difference between a field name and a type name. My preference would be to keep our current structure for naming but use a different formatting rule for type names, field names, and string literals.
- Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same.
- Property names are all lowercase, using underscores, e.g. “created_by_ref”
Is there a reason why everything couldn’t just be the same? Remembering the names of all the things in STIX/TAXII is hard enough, I’d rather not add a thing to remember if we don’t have to. My vote would be for all lowercase, all dashes.
Thank you. -Mark
Hm, I would not have said these same things. We had a short discussion in the doc comments earlier, my assumption was: - Type names are all lowercase, using dashes, e.g. “attack-pattern”. These type names, when used in JSON, appear exactly the same.
- Property names are all lowercase, using underscores, e.g. “created_by_ref”
- String enum values, e.g. relationship value/nature, are lowercase using dashes, e.g. “has-source"
As we start writing normative text in Google docs we should agree about some basic rules for formatting and naming, so we don’t have to fix it later (coming from someone who had to do that to 15 STIX documents and 94 CybOX documents….). Here are is what we are currently doing for formatting: · Use Arial/11pt for basic text. · Use the provided header styles · Use Consolas/11pt for JSON examples (color: RGB(199, 37, 78)) with background (color: RGB(249, 242, 244)) · Property names in bold For naming, we haven’t been consistent… here is a list of proposed rules · Type names do not have the “Type” suffix · Type names are camel case · Property names are all lower case, using dashes, not underscores. Should type names and property names be in a special font and/or color? Currently it is the same as the JSON examples. Comments?
|