field and type name question/suggestion

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

 

On Feb 11, 2016, at 6:42 AM, Barnum, Sean D. <> wrote:

>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

From: <> on behalf of John Wunder <>Date: Thursday, February 11, 2016 at 8:46 AMTo: "" <>Subject: Re: [cti] Suggested formatting for normative text

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.

From: Mark Davidson <>Date: Thursday, February 11, 2016 at 7:53 AMTo: "Wunder, John A." <>, Rich Piazza <>, "" <>Subject: Re: [cti] Suggested formatting for normative text

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

From: <> on behalf of "Wunder, John A." <>Date: Wednesday, February 10, 2016 at 2:48 PMTo: "Piazza, Rich" <>, "" <>Subject: Re: [cti] Suggested formatting for normative text

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"

From: <> on behalf of Rich Piazza <>Date: Wednesday, February 10, 2016 at 2:41 PMTo: "" <>Subject: [cti] Suggested formatting for normative text

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?

Attachment:
signature.asc

Description: Message signed with OpenPGP using GPGMail