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.
attachment
description:message
fileLocation
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 <>
Sent: Wednesday, April 25, 2018 3:37 PM
To: Larry Golding (Comcast) <>;
Subject: RE: [sarif] RE: I don't think we need an "attachment" object any more
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: <> On Behalf Of Larry Golding (Comcast)
Sent: Wednesday, April 25, 2018 1:52 PM
To:
Subject: [sarif] RE: I don't think we need an "attachment" object any more
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) <>
Sent: Wednesday, April 25, 2018 1:47 PM
To: '' <>
Subject: RE: I don't think we need an "attachment" object any more
Importance: High
Also, I would add a new permittted value analysisToolLogFile in file.roles.
From: Larry Golding (Comcast) <>
Sent: Wednesday, April 25, 2018 1:41 PM
To: '' <>
Subject: I don't think we need an "attachment" object any more
Importance: High
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[]
-attachment
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
