[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Potential Version 2.6 Modification - Versions on RegistryObjects(Was Re: [regrep-cc-review] Association Core Components - Represent withAssociations)
Chiusano Joseph wrote: >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? > All the other attributes stability etc. were lumped into new Version class. None are left so we can get rid of this class altogether. BTW any chance we could use internet style replies (like this one) instead of the <Quote></Quote>. I cannot even recognize my own comments. In such context sensitive conversation this would be a huge help. Thanks. > >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 >> -- Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]