[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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) <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]