[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]