RE: [sarif] RE: I don't think we need an "attachment" object any more

From
Michael Fanning <>
Date
2018-04-25T22:36:42+00:00
ID
Thread
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