OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sarif] Provisional draft includes all changes


With regard to #2 (making columnKind optional) I now agree with Michael. I filed Issue #191 (CSD.1): “run.columnKind is optional”, as follows:

The TC approved #178, which defined the required property run.columnKind with values "utf16CodeUnits"and "unicodeCodePoints". But neither of these values is sensible for a tool that does not process text files.

To fix this problem, we will make the property optional. This approach has the following features:

·         Tools that emit columnKind are better off than they were before, because consumers now know how to interpret the tool’s column counts.

·         Tools that do not emit columnKind are no worse off than they were before. Consumers had to guess before, and they still have to guess.

·         We do not specify a default (a very contentious issue which we can sidestep).

·         We do not have to specify a "none" value for use by non-text-processing tools. Nowhere else in SARIF does an enumerated property have a "none" or "unknown" value.

I will do the following, similar to how I approached Issue #189:

 

  1. Make the changes directly in the provisional draft.
  2. Place a change-barred version in the ChangeDrafts/Accepted folder.
  3. In the multi-part motion on the e-ballot, add a part to approve this change.
  4. If the change is rejected, back it out of the provisional draft and move the change draft to the Rejected folder.

 

Thanks,

Larry

 

From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast)
Sent: Friday, June 8, 2018 8:54 AM
To: 'Michael Fanning' <Michael.Fanning@microsoft.com>; sarif@lists.oasis-open.org
Subject: RE: [sarif] Provisional draft includes all changes

 

I filed Issue #189, “Make result.workItemUris an array.”

 

From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast)
Sent: Friday, June 8, 2018 8:41 AM
To: 'Michael Fanning' <Michael.Fanning@microsoft.com>; sarif@lists.oasis-open.org
Subject: RE: [sarif] Provisional draft includes all changes

 

We agree on #1. I’ll file an issue and make the change in the provisional draft. I’ll put a change-barred version in the “Accepted” folder. I can move it to “Rejected” and revert the change in the unlikely event the TC rejects it in the e-ballot.

 

As for #2: As you say, Jim worried that if we chose the wrong default, a tool that accidentally omitted columnKind would induce unexpected behavior in the consumer (for example, the consumer would interpret columns as UTF-16 code units when the producer meant them to be interpreted as Unicode code points).

 

But if we do what you say, a tool that accidentally omits columnKind will induce unpredictable behavior in the consumer (some consumers might interpret the columns as UTF-16 code units, and others as Unicode code points). To my mind, that’s worse.

 

I still prefer my proposal of keeping columnKind as required (which is what the TC approved), and adding a value "none" that non-text-processing tools can use.

 

Larry

 

From: Michael Fanning <Michael.Fanning@microsoft.com>
Sent: Thursday, June 7, 2018 5:20 PM
To: Larry Golding (Comcast) <larrygolding@comcast.net>; sarif@lists.oasis-open.org
Subject: RE: [sarif] Provisional draft includes all changes

 

My suggestion:

 

  1. Make workItemUris an array, this is consistent with similar data
  2. Don’t make columnKind required. If it isn’t available, then the consumer doesn’t have any information and must take its chances. We can return to the issue of a default value in CSD2. Jim’s primary concern in the TC was defining the wrong default value, so we’ve preserved that. Anyone producing CSD1 SARIF today can do so without worrying about future changes in the default value simply by being scrupulous in emitting columnKind. Please note that if you aren’t a text processing thing, then the default value doesn’t really matter if columnKind isn’t present, because there shouldn’t be any column data in the SARIF log…

 

Michael

From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast)
Sent: Wednesday, June 6, 2018 4:32 PM
To: sarif@lists.oasis-open.org
Subject: [sarif] Provisional draft includes all changes
Importance: High

 

Here is the status:

 

  • I update the provisional draft with the changes we approved today, as amended.
  • The schema (and the schema changes document) is up to date with all changes.
  • I added the list of acknowledgments (supplied by Stefan) to the provisional draft.
  • I updated the HTML version of the provisional draft.
  • There are two issues we must address before asking OASIS to submit our CSD.1:
    1. Array-valued result.workItemUris – yes or no in CSD.1?
    2. Value of columnKind for tools that don’t process text files.

 

I propose:

 

  1. Yes, accept array-valued result.workItemUris in CSD.1.
  2. Keep columnKind as required, but introduce enumerated value "none" for tools that don’t process text files.

 

I will wait for resolution of those two issues before creating the ZIP. May I ask Michael to help me drive resolution of the two issues (by which I mean, gently nudge people who care about them to weigh in – I’m not good at that), and David and Stefan to adjust our balloting process to accommodate the changes, if we accept them.

 

Thanks,

Larry



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]