Re: [regrep] Groups - regrep-modules.pdf uploaded

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

rmartell@galdosinc.com wrote:

>The document regrep-modules.pdf has been submitted by Richard Martell (rmartell@galdosinc.com) to the OASIS ebXML Registry TC document repository.
>
>Document Description:
>This is a proposal for incorporating the concept of an extension module into ebRIM. In effect a module is a registry package that constitutes an 'expansion pack' for handling certain types of content.
>
>Download Document:  
>http://www.oasis-open.org/apps/org/workgroup/regrep/download.php/9084/regrep-modules.pdf
>
>View Document Details:
>http://www.oasis-open.org/apps/org/workgroup/regrep/document.php?document_id=9084
>
>
>PLEASE NOTE:  If the above links do not work for you, your email application
>may be breaking the link into two pieces.  You may be able to copy and paste
>the entire link address into the address field of your web browser.
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>  
>
Richard,

The idea of regrep extension modules you introduce in this paper are a 
timely and important solution to a growing need; the need to customize 
ebXML Registry to the needs of domain specific information models.

I have been observing that ebXML Registry is being used in many 
different vertical domains from Medical, Government, Defense, 
Statistics, Automotive, Travel, and of course Geospatial. Each domain 
has its own unique information model. Fortunately, each model can use 
the existing extension capabilities of ebRIM to map their information 
model to ebRIM. Your paper proposes doing such mappings in a more 
standard way by defining normatively how such mapping should be done.

I think this is an important issue for our standard to address soon 
because of the variety of extensions being defined by various vertical 
domains.

One area that your paper does not currently address is how to add new 
classes to ebRIM complete with new attributes, XML schema binding and 
SQL bindings. I call this "type extensibility". We currently have 
limited type extensibility with the ability to add to ObjectTypes. We 
also have limited "attribute  extensibility" with  Slots.

I have heard from several users that ebXML Registry standard should 
provide some way to add entire new domain specific classes to ebRIM via 
an extensibility mechanism that allows defining the Class, the 
attributes in the class as well as SQL and XML Schema bindings.

Do you feel that this true type extensibility requirement is very important?
If so do you think this is something that we should consider as part of the
extension modules proposal you have introduced to the TC?

-- 
Regards,
Farrukh