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]