[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sarif] RE: I don't think we need an "attachment" object any more
I have clearly been a bit confused, my apologies. Here is my current open issue: a tool might want to provide two sets of annotations that are associated with a single file in the file table. Can you describe how this would work in the new proposal? If there’s a one-to-one association
with a set of annotations and a file, that would be unappealing. From: Larry Golding (Comcast) <larrygolding@comcast.net>
To emphasize: the only thing this proposal does is get rid of an object that does nothing useful except carrying a message, and putting that message it what is IMO a more appropriate place (on the file object). From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Comcast) Merging threads. Michael wrote:
So attachments used to have regions which could be used to annotate a region in the attachment. If simplify to a file location, don’t we lose it? The same file in the table could be annotated in separate ways, so we can use a unique file location to for this.
The answer is: No. Attachments have never had regions. An
attachment is (and always has been) nothing but a
fileLocation (uri +
uriBaseId) + a description. The thing that has a region is a
physicalLocation. So for example, result.conversionProvenance is an array of
physicalLocation objects, so you can see the region(s) of the analysis tool log file(s) that were converted into the SARIF
result object. You might be confusing attachment with
annotation. From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Comcast) This change does not affect annotations. Annotations don’t live on the
attachment object, they live on the
location object: location physicalLocation ... annotations:annotation[] ... annotation message locations:location[] … which is indeed a little twisted, but anyway, it’s not related to attachments. To your request for a more comprehensive view of the result of my proposal: invocation commandLine:string arguments:string[] ... attachments:fileLocation[] # Instead of attachment[]. result ruleId:string message ... attachments:fileLocation[] # The only other place attachment object was used.
file fileLocation mimeType:string contents:fileContent ... roles:string[] # Since we just put this here...
description:message # ... it seems natural for this to be here as well. Larry From: Michael Fanning <Michael.Fanning@microsoft.com>
What has happened to the annotations that are associated with an attachment? Can you provide a more comprehensive view of the final type definitions you have in mind? From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Comcast) I’m sorry, I was so excited about this idea that I was inaccurate.
conversionProvenance is of type
physicalLocation[] (and physicalLocation =
fileLocation +
region), not of type attachment[]. And it’s the
invocation object, not the
run object, that has an attachments property. But I still think replacing the
attachment object with the file.description property is a good idea! From: Larry Golding (Comcast) <larrygolding@comcast.net>
Also, I would add a new permittted value
analysisToolLogFile in file.roles. From: Larry Golding (Comcast) <larrygolding@comcast.net>
As you know, both run and
result have a property
attachments of type attachment[].
result also has
conversionProvenance of type attachment[]. An
attachment is nothing but a
fileLocation plus a description. The spec says this about
description: An attachment object
SHOULD contain a property named description whose value is a
message object (§3.9)
describing the role played by the attachment. The “role”, huh? Be we just added a
roles property to the file object! So perhaps the
file object is also the natural place for
description. Then we don’t need the
attachment object, and instead we have: file =role
+description:message run: ~attachments:fileLocation[] result: ~attachments:fileLocation[] ~conversionProvenance:fileLocation[]
I stumbled on this as I was starting to write the words for
Issue #134, “conversion.analysisToolLogFileLocation should be an array”, which made me look at
result.conversionProvenance and wonder why it was an
attachment[]. If we agree, I’d like to do this in the same change draft as the one I’m writing for #134, since they both touch
result.conversionProvenance. Thoughts? Larry |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]