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

[Monica Martin <monica.martin@sun.com>]

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:

mm1: Farrukh, perhaps we should look at the suggestions in discussion 
within UBL and OAG-CC who submitted comments to the CCTS implementation 
verification group.  All of these may or may not apply:

Code List. Identifier

Code List. Version. Identifier

Code List. Agency. Identifier

Code List. Agency Scheme. Identifier

Code List. Agency Scheme Agency. Identifier


This is related to codes although this is a good reference point (Note, 
could the version be determined by other than the registry owner - for 
example, they use a code list and store them locally in a registry for 
use, but the actual officiating agency is some other authority.  If this 
is too benign a case, I can understand).

And too, RosettaNet has proposed some versioning attributes on what 
looks to be loosely the same as a core component.  In addition to the 
major and minor version, they have proposed:

    * Date defined
    * Date minor version
    * Date major version

Most of the other attributes, I believe we probably already have 
defined. Thanks.

>
> *    <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"/>
>
>
>
>