OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[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


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.  

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...

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]