[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep-cc-review] Association Core Components - Represent withAssociations
Here is another issue from the CC Review discussions that I'd like to raise up to the Registry TC. Below, Farrukh proposes the optional inclusion of "version" on RegistryObject, and also the possible elimination of RegistryEntry from our architecture. Comments are welcome and approeciated. Thanks, Joe Monica Martin wrote: > > Farrukh Najmi wrote: > > > Have given up trying to include context from the thread for this reply > > and will paraphrase instead.... > > > > One issue with the representation of ACC as an Association that I have > > heard is that an Association is a RegistryObject and RegistryObjects > > do not have version attributes. Version attributes are desired for > > ACC. Therefor the argument goes that we should not use Association for > > representing ACC. > > > > Maybe we should not limit our modeling choices by the limitation of > > current RIM. > > > > Nikola and I have long felt that version should have been a > > RegistryObject attribute (actually to take it a step further I have > > never felt comfortable with having RegistryEntry in the first place > > for this very reason). > > > > One possibility is tha we could consider making the proposal that in > > 2.6 we modify RIM w.r.t version related info so that Version is > > optionaly included as part of a RegistryObject and RegistryEntry is > > eliminated. The only issues I see with this is: > > > > -It makes a big RIM change late in V3 cycle > > -Version work would have to think through implications ofr > > supporting full version control in V4 > > > > The proposed schema changes could look something like: > > > > 1. Removes RegistryEntryType (not shown in schema fragments) > > > > 2. Replace RegistryEntryType with RegistryObjectType (not shown in > > schema fragments) > > > > 3. Add VersionType as follows: > > mm1: Farrukh, perhaps we should look at the suggestions in discussion > within UBL and OAG-CC who submitted comments to the CCTS implementation > verification group. All of these may or may not apply: > > Code List. Identifier > > Code List. Version. Identifier > > Code List. Agency. Identifier > > Code List. Agency Scheme. Identifier > > Code List. Agency Scheme Agency. Identifier > > This is related to codes although this is a good reference point (Note, > could the version be determined by other than the registry owner - for > example, they use a code list and store them locally in a registry for > use, but the actual officiating agency is some other authority. If this > is too benign a case, I can understand). > > And too, RosettaNet has proposed some versioning attributes on what > looks to be loosely the same as a core component. In addition to the > major and minor version, they have proposed: > > * Date defined > * Date minor version > * Date major version > > Most of the other attributes, I believe we probably already have > defined. Thanks. > > > > > * <complexType name = "VersionType"> > > <annotation> > > <documentation xml:lang = "en"> > > Defines a version for a RegistryObject. > > </documentation> > > </annotation> > > <sequence minOccurs = "0" maxOccurs = "unbounded"> > > <element ref = "tns:Slot"/> > > </sequence> > > <attribute name = "expiration" use = "optional" type = > > "dateTime"/> > > <attribute name = "majorVersion" default = "1" type = > > "integer"/> > > <attribute name = "minorVersion" default = "0" type = > > "integer"/> > > <attribute name = "stability" use = "optional"> > > <simpleType> > > <restriction base = "NCName"> > > <enumeration value = "Dynamic"/> > > <enumeration value = "DynamicCompatible"/> > > <enumeration value = "Static"/> > > </restriction> > > </simpleType> > > </attribute> > > > > <attribute name = "userVersion" use = "optional" type > > = "tns:ShortName"/> > > </complexType> > > <element name = "Version" type = "tns:VersionType"/> > > * > > 4. Update RegistryObjectType as follows: > > > > <complexType name = "RegistryObjectType"> > > <annotation> > > <documentation xml:lang = "en"> > > id may be empty. If specified it may be in urn:uuid format or be in some > > arbitrary format. If id is empty registry must generate globally > > unique id. > > > > If id is provided and in proper UUID syntax (starts with urn:uuid:) > > registry will honour it. > > > > If id is provided and is not in proper UUID syntax then it is used for > > linkage within document and is ignored by the registry. In this case the > > registry generates a UUID for id attribute. > > > > id must not be null when object is being retrieved from the registry. > > > > </documentation> > > </annotation> > > <sequence minOccurs = "0" maxOccurs = "1"> > > <element ref = "tns:Name" minOccurs = "0" maxOccurs = "1"/> > > <element ref = "tns:Description" minOccurs = "0" maxOccurs > > = "1"/> > > <element ref = "tns:Slot" minOccurs = "0" maxOccurs = > > "unbounded"/> > > <element ref = "tns:Classification" minOccurs = "0" > > maxOccurs = "unbounded"/> > > <element ref = "tns:ExternalIdentifier" minOccurs = "0" > > maxOccurs = "unbounded"/> > > *<element ref = "tns:Version" minOccurs = "0" maxOccurs = > > "1"/>* > > </sequence> > > <attribute name = "id" type = "anyURI"/> > > > > <!--home attribute is required only for replicas of remote > > Objects--> > > <attribute name = "home" type = "anyURI" use="optional"/> > > > > <attribute name = "objectType" use = "optional" type = "anyURI"/> > > <attribute name = "status"> > > <simpleType> > > <restriction base = "NCName"> > > <enumeration value = "Submitted"/> > > <enumeration value = "Approved"/> > > <enumeration value = "Deprecated"/> > > <enumeration value = "Withdrawn"/> > > </restriction> > > </simpleType> > > </attribute> > > </complexType> > > <element name = "RegistryObject" type = "tns:RegistryObjectType"/> > > > > > > > >
begin:vcard n:Chiusano;Joseph tel;work:(703) 902-6923 x-mozilla-html:FALSE url:www.bah.com org:Booz | Allen | Hamilton;IT Digital Strategies Team adr:;;8283 Greensboro Drive;McLean;VA;22012; version:2.1 email;internet:chiusano_joseph@bah.com title:Senior Consultant fn:Joseph M. Chiusano end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]