[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep-cc-review] Association Core Components - Represent with Associations
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"/> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]