[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO
Piazza, Rich wrote this message on Wed, Jun 14, 2017 at 20:58 +0000: > I don't think we should give up on the idea of reusing Locations so quickly. Assuming we go with Locations as SDOs, it certainly is a problem if you reuse someone's Location and they change it from underneath you. I was first thinking that there should be immutable SDOs - in other words, the unique USA Location SDO CAN'T be changed. If we had a set of the common ones (defined in some library/repo somewhere) then we could just use their ids. Duplicates are allowed, but hopefully few people would need to create their own USA Location SDO. I was thinking of an extra property (on all SDOs?) - final. If final is true for an SDO, then a new version couldn’t be created. I'd like to point out we already have an "imutable" SDO. The versioning spec specifically calls out that if you make a material change to an SDO, that you need to create a new one, and not reuse an existing one. We might want to extend the text to say that if you created an SDO and link it, but that the linked SDO was incorrect, say USA vs USA Major Islands, that you need to create a new Location object, and revoke the original relationship, and that changing the original object is NOT the correct work flow. The idea of a final flag is an interesting one, but what would the handling of when a new final object is created? Or a new one that had the modified date before the other one? This is just changing the problem slightly w/o solving it. Other solution is to simply say the Location objects cannot be versioned. I cannot really think of a good reason/way to version/update a Location object w/o materially altering it's meaning. > Adding immutable objects to the spec might be a good idea in general, but I think a simpler way to handle this is just to "trust" that the library/repo contains objects that will not change. In other words, locations created by a certain (well-known) identity (SDO-Immutable-Library) could be reused with little concern that they are going to change. And if they DO change - maybe that is a feature - after all, all those Soviet-Union Location SDOs are no longer too useful... -- John-Mark
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]