OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

[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]