My suggestion:
Make workItemUris an array, this is consistent with similar data
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: <>
On Behalf Of Larry Golding (Comcast)
Sent: Wednesday, June 6, 2018 4:32 PM
To:
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:
Array-valued
result.workItemUris – yes or no in CSD.1?
Value of
columnKind for tools that don’t process text files.
I propose:
Yes, accept array-valued
result.workItemUris in CSD.1.
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
