[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Potential Version 2.6 Modification - Versions on RegistryObjects (Was Re: [regrep-cc-review] Association Core Components - Represent withAssociations)
Please see comments below. <Quote1> 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. </Quote1> Just a slight clarification - I think you meant to write "ASCC" instead of "ACC", as we've been considering whether or not to represent ASCCs with Associations. But the main point is still very valid. <Quote2> Maybe we should not limit our modeling choices by the limitation of current RIM. </Quote2> Absolutely. <Quote3> 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. </Quote3> I like this idea - but what about the other RegistryEntry attributes? The rest of the ideas sound great to me - I would recommend that we raise this to the Registry TC, if you'd like. Joe 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: > > * <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"/> > > -- > Farrukh
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]