[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti] Suggested formatting for normative text
Do you mean “Type names in
bold
courier”. I think all language terms should be in the same font. I don’t know if you noticed, but in the google docs all of the field names are in bold
L BTW – I made this comment in one of the docs related to this line: marking_refs field (of type
marking-refs) From the STIX 1.2 spec - there were many types and properties that had the same name - except type names had the "Type" suffix. I don't want to go back to that - but maybe camel case is better. These look the same.
I know we can use different colors/fonts in the documents, but otherwise, I think it is going to be confusing – like in an email. From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Kirillov, Ivan A. I agree as well. How about:
·
Field names in
courier
·
Type names in
bold
·
String literals in
italics -Ivan From:
<cti@lists.oasis-open.org> on behalf of Sean Barnum <sbarnum@mitre.org> >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:
<cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org> 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 <mdavidson@soltra.com>
·
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:
<cti@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> 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:
<cti@lists.oasis-open.org> on behalf of Rich Piazza <rpiazza@mitre.org> 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? |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]