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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [regrep] [Fwd: ObjectRef and RegistryObject need common basetype]

Farrukh Najmi wrote:

> the issue/suggestion below seems to make good sense from an OO stand 
> point. 

Looking at the suggestion in some detail I note that we made a change in 
V3 schema to use OO techniques in RegistryObjectList to simplify V2 
schema such that instead of itemizing every type of RegistryObject 
individually we simply allow the base type RegistryObject to be used. 
However it still had the complexity of treating RegistryObject and 
RegistryObjectRef separately.

V2.1 Schema:

   <complexType name = "LeafRegistryObjectListType">
       <choice minOccurs = "0" maxOccurs = "unbounded">
           <element ref = "tns:ObjectRef"/>
           <element ref = "tns:Association"/>
           <element ref = "tns:AuditableEvent"/>
           <element ref = "tns:Classification"/>
           <element ref = "tns:ClassificationNode"/>
           <element ref = "tns:ClassificationScheme"/>
           <element ref = "tns:ExternalIdentifier"/>
           <element ref = "tns:ExternalLink"/>
           <element ref = "tns:ExtrinsicObject"/>
           <element ref = "tns:Organization"/>
           <element ref = "tns:RegistryPackage"/>
           <element ref = "tns:Service"/>
           <element ref = "tns:ServiceBinding"/>
           <element ref = "tns:SpecificationLink"/>
           <element ref = "tns:User"/>

V2.5 Schema (note simplification from v2.1):

 <complexType name="RegistryObjectListType">
     <element maxOccurs="unbounded" minOccurs="0" 
     <element maxOccurs="unbounded" minOccurs="0" 

Mei's suggestion would allows V2.5 schema to be made further OO and 

 <complexType name="RegistryObjectListType">
     <element maxOccurs="unbounded" minOccurs="0" ref="tns:Identifiable"/>

IMO, such simplification is in the right direction.
The impact on the schema should be quite minor. The benifit will be 
simlification of implementations.

Can we add this to our agenda for next week. Thanks.


> -------- Original Message --------
> From: Mei-Xing Zhao <Mei-Xing.Zhao@Sun.COM>
> Dear ebXML TC,
> During our implementation of the ebXML Registry version 2.5 
> specification we came across a minor limitation in the rim.xsd schema 
> and would like to suggest a simple improvement to make implementation 
> easier.
> Currently the rim.xsd schema has the RegistryObjectType and 
> ObjectRefType defined. Both these types have an id and home attributes 
> defined. In many situations during implementation it is desirable to 
> treat an ObjectRef and RegistryObject symmetrically. This is currently 
> not possible because the current schema does not provide a common base 
> type for RegistryObjectType and ObjectRefType.
> The enhancement we would like to propose is to add a common base type 
> called IdentifiableType from which we derive both RegistryObjectType 
> and ObjectRefType :
> IdentifiableType
>                                      |
>                         ----------------------------
>                         |                          |
>                 RegistryObjectType            ObjectRefType
> In such an approach factor out the id and home attributes that are 
> common to both RegistryObjectType and ObjectRefType and put them in 
> the new IdentifiableType.
> Regards,
> Mei

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]