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] Groups - regrep-modules.pdf uploaded


Farrukh Najmi wrote:

> 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.
> 


This proposal derives from work we've been doing in OGC test beds to
define RIM extensions that are tailored to meet specific application
needs. Since a "mother of all registries" is an unlikely prospect in
most situations, we needed a mechanism that enables providers to package
together a cohesive set of extensions in a flexible manner; the basic
idea is that modules are logical "plug-ins" for handling/searching
registry content.

While we've focused on rather specialized geospatial extensions, the
concept can be generally applied. A module itself is then subject to
lifecycle management on the part of some authority, and it can be
readily advertised and queried.


> 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.
> 


Yes, the proposal currently emphasizes "soft" extensions that make use
of the built-in extensibility points. However, "hard" extensions that
introduce new type definitions can also be accommodated. For such cases,
a module would also include an "XmlSchema" member that defines
the additional elements and types.


> 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?
> 


I would say it's probably worth accommodating, but with some
constraints--see point a) below. Also, to make this work effectively
we can rely on the substitution mechanism to reduce the coupling between
schemas (i.e., so that adding a new extension element doesn't call for
the parent OASIS schema(s) to be modified). So a few (albeit
backward-compatible) schema tweaks might be required to facilitate this:

a) Adding derivation restrictions to ebRIM/ebRS types in order to
   exert better control over the introduction of new types;

b) Defining substitution groups as "hooks" where appropriate


If folk are not averse, I can embellish the modules proposal along
these lines.


-- 
Richard Martell         Public PGP key: <http://www.galdosinc.com/pgp/>
Galdos Systems, Inc.      tel: +1 604-484-2765  |  fax: +1 604-484-2755

Opinions, conclusions, recommendations, and other information presented
in this message are not given or necessarily endorsed by my employer or
firm. If the digital signature is invalid, I did not send this message.



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