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: Change draft for #179 (plugins) and #311 (notification metadata)

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”.




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:


  1. It makes message string lookup more complicated, because:
    1. Notification messages can now occur either as global strings or in the newly introduced notification metadata, whereas before, they were always global.
    2. Messages of all kinds now occur in toolComponent objects (tool.driver and tool.extensions[]), whereas before, they were always in run.resources.
    3. 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, “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.


  1. 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.






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