Let’s just make sure that the ballot text is clear: a vote of NO will mean that we will not have any RFC2119 language at all regarding the length of strings in the normative specifications.
A vote of YES will mean that we will have some 2119 language and there will be a follow-on discussion to decide how length is measured and what type of statements we should make.
John
From:
<cti-stix@lists.oasis-open.org>, Eric Burger <ewb25@georgetown.edu> on behalf of Eric Burger <Eric.Burger@georgetown.edu>
Date: Tuesday, June 7, 2016 at 5:28 PM
To: John-Mark Gurney <jmg@newcontext.com>
Cc: <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Motion for Ballot on Lengths
Disagree. See inline.
Eric,
Not exactly, and I'll make sure it's clarified in the ballot.
There are two yes versions, the MUST and the SHOULD. Yes the SHOULD version is effectively a no limit,
Precisely. It is no limit.
but it does provide guidance on the limits which can be useful for UI, etc.
Incorrect on two counts. Count one is there is not limit. Count two is what gets displayed on a UI is purely an implementation detail. See below.
W/ the SHOULD it advices UI designers that only the first 64 units are significant, and that if a field is longer than that, they may truncate it, or display a more/ellipses/tool tip to expand/display the remaining part of the field.
Which is purely an implementation detail that has zero impact on what is in the data base or what is sent over the wire. As such, the statement has less than no meaning, because a handful of people will interpret it to mean they can never
send more than 64 units, may reject something with 65 units, or not care about a limit.
If we want to have a style guide, let’s produce a style guide. That is different than normative language as to what goes into a STIX JSON object.
On Tue, Jun 7, 2016 at 1:58 PM, Eric Burger <Eric.Burger@georgetown.edu> wrote:
Just a reminder that “SHOULD be 1 to 64 [units] long and MAY be longer than 64 [units]” is the same as “There are no limits.”
Should the STIX specification provide guidance on the lengths supported by free form fields, such as (but not limited to) description, title, and open vocab?
No, there should be no lengths limits.
Yes, the spec should specify length limits for free for fields.
Note: If yes, there will be a number of additional questions to follow, but lets resolve first if we even need to ask the remaining questions. One main issue is if the lengths should be mandatory (MUST) or advisory (SHOULD).
|