David, I don't agree with this assertion:
[D.K.] A hasFiles property on the Package, once created by the OEM, implies that the list of files will remain static for that version of the package, while a CONTAINS relationship implies that later documents can modify the list of files in a given package. The reason I disagree is that I can find no documentation in the specification of such an intention. Unless this is clearly spelled out in an authoritative document that we can reasonably expect all creators of SPDX documents to have read, then it's a guarantee that different creators will reach different conclusions and use hasFiles and relationships with different intentions or no intentions at all. Which will generate further confusion. For example, it never occurred to me that the use of one over the other implied anything. In my mind they are identical. Which as a digression, is a good reason to try and eliminate the possibility of duplication in V3.0 by having one and only one way to assert a relationship between two elements. Simon On Mon, Dec 13, 2021 at 11:31 AM David Kemp <[email protected]> wrote: > Gary, > > There are two possibilities - the actual package is updated or not. > You're thinking of the first case where a new version of the package > artifact is released that AMENDS the previous artifact. > > I'm thinking of the second case, where there is no new artifact and the > package OEM made an assertion that "These are the files in this package". > Then a different document creator comes along and makes a mistake. Either > properties or relationships can work correctly, but relationships are > *intended* to be updated, whereas property values are *intended* to be > static for a given object. It's cognitively easier to detect an error that > should never happen vs. detecting something that follows the normal flow of > operations but is an error in the specific case of adding a new CONTAINS > relationship when the containing artifact hasn't changed. > > Dave > > > On Mon, Dec 13, 2021 at 1:39 PM Gary O'Neall <[email protected]> > wrote: > >> Hi David, >> >> >> >> Thanks for the analysis and reply – very good question and points. >> >> >> >> Responses inline below. >> >> >> >> Gary >> >> >> >> *From:* [email protected] <[email protected]> *On Behalf >> Of *David Kemp >> ... >> > A hasFiles property on the Package, once created by the OEM, implies that >> the list of files will remain static for that version of the package, while >> a CONTAINS relationship implies that later documents can modify the list of >> files in a given package. >> >> *[G.O.] A very interesting point. Using the hasFiles property would >> require someone amending the Package definition to include another file to >> create a new unique Package with the superset hasFiles property. The >> amended Package should have an AMENDS relationships to indicate the >> change. It would be much simpler to have set of CONTAINS relationships >> where someone could just add an additional Relationship. In both cases, >> however, we would have the Document and Creation information to clearly >> separate which is the original and which was changed. BTW – The Document >> containing the amended Package should also have an Amends relationship to >> the original Document. Thinking through this, I think both approach could >> reliably handle the situation, but using Relationships is simpler.* >> >> ... >> > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4292): https://lists.spdx.org/g/Spdx-tech/message/4292 Mute This Topic: https://lists.spdx.org/mt/87646486/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
