[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)
<Quote> 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. </Quote> I wish I could - unfortunately my e-mail client here at Booz Allen does not allow me to do this (unless I am misunderstanding) - it inserts a bunch of ">"s all over the place. I would appreciate your help and insight - so if you have any pointers for me in how to do this, please e-mail me offline. Joe Farrukh Najmi wrote: > > 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
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]