See Detected a potential breaking change in Common IM that doesn't seem to be documented
That change was introduced recently without much attention on that is a breaking change. So some restriction was already added, before I thought a folder item could point to a VERSION or even a LOCATABLE.
Then the other discussion here is, if the target is only VERSIONED_OBJECT, then can that be ANY VERSIONED_XXX?
Thomas’ argument is some VERSIONED_XXX types don’t make sense there, which I agree with, though strictly by the spec, they are allowed. In terms of conformance testing, what is not constrained in the spec, is allowed.
I don’t see any issues on:
- allow any target on FOLDER items (including VERSION and LOCATABLEs)
- include the VERSIONED_OBJECT types that don’t make sense there but are still allowed
Though in the case of 2. even if it’s not a hard rule to avoid those types as targets, it would be useful to have a comment there in the spec. Then in the conformance spec we can take that comment and say, for conformance that comment is really a hard rule so we don’t allow this case to happen (we check it doesn’t work or we don’t check it at all).
Not really the focus of the discussion, my comment wasn’t really about supporting links, but that supporting more types on the REF target could lead to more code needed if the software does checks the target exists and different types of targets are stored in different places (e.g. tables).
Agree. That is what I tried to point out in the other thread Detected a potential breaking change in Common IM that doesn't seem to be documented
I think it’s valid to have that open and use it as you need, since the object ref could point to a party, locatable and other types (now that I say this, not sure why we have LOCATABLE_REF and PARTY_REF since PARTY is LOCATABLE).