[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
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.
From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Michael Fanning 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]