Re: [regrep-cc-review] Association Core Components - Represent withAssociations

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<Quote>
Have given up trying to include context from the thread for this reply 
and will paraphrase instead....
</Quote>

I agree that the threads - although quite rich - have become somewhat
convoluted. I'm thinking of ways to make it easier - for example, I may
"chop up" a thread into various subtopics. I also welcome any
suggestions that folks may have from their experience (or even not from
their experience!).

As always, I appreciate everyone's contributions. Let's keep this great
momentum going...

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