Please read carefully. Not only is this a large change draft, but the explanation of what has
not yet been done is also complicated.
I pushed a change draft for Issue #179: “Consider whether SARIF covers plug-ins/rules versioning sufficiently” and Issue #311: “Provide full metadata objects for notifications”.
Documents/ChangeDrafts/Active/sarif-v2.0-issues-179-311-plugins-and-notification-metadata.docx
We will move its adoption at TC Meeting #32 on Wednesday, February 20th.
This is a huge change, and it has certain implications that this change draft
does not fully address:
- It makes message string lookup more complicated, because:
- Notification messages can now occur
either as global strings or in the newly introduced notification metadata, whereas before, they were always global.
- Messages of all kinds now occur in
toolComponent objects (tool.driver and
tool.extensions[]), whereas before, they were always in
run.resources.
- We still have the third dimension of plain text strings
vs. Markdown strings – and that dimension was handled badly in the existing design. In the existing design, rule messages were split between
rule.messageStrings and
rule.richMessageStrings, but global messages were stored together in
rule.messageStrings.
Those three things together would make a full description of the resulting string lookup procedure very complicated. However, at TC 31 we also approved a design for #319, “Consider converging all messages into a
common format strings object.” This unifies the treatment of plain text and “rich” (Markdown) message strings, and essentially removes the third dimension from the lookup procedure.
Therefore: In the change draft you have before you, Section 3.11.6.2, “Embedded string resource lookup procedure,” is incomplete. It’s good up until the sentence “If the consumer can render rich text messages.” Ignore the rest.
Here’s my reasoning: If I had left this section alone, it would have been completely wrong. On the other hand, if I had
finished writing it, it would have been a waste of effort, because the complications in the unfinished section would have been undone when I wrote the change draft for #319. So IMO the change draft is the best compromise between (1) having this change
draft be completely consistent, and (2) avoiding wasted work, in the interest of getting to the end as quickly as possible.
- It affects the format of “localized resource files”. Until now, a localized resource file was a stripped-down SARIF log file that basically just contained
run.resources. I could just change the definition of the format to contain a
run.tool instead, but actually I’m going to argue for removing localization support (and
tool.language) entirely. So I’m leaving this alone for now, again on the principle that it’s better to have an intermediate provisonal draft be inconsistent than to spend time updating a feature that might be changed
or removed.
When I move to adopt this change draft, it will be with the understanding that we still have to address these two issues.
Thanks,
Larry