Farrukh Najmi wrote:
> wrote:
>
>> The document regrep-modules.pdf has been submitted by Richard Martell
>> () 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.
