[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] Groups - regrep-modules.pdf uploaded
Richard Martell wrote: >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. > > > > +1 on updating modules proposal to support"hard" extensions. Ideally we should cover how extension XML schemas are defined, what constraints must they observe and how the XML Schema maps to SQL schema extensions. A 90% solution here would go a long way. I would also like to propose that the modules proposal be on the agenda for the next TC meeting with enough time allocated for a substance filled discussion. Thanks again for taking the lead on this important proposal. -- Regards, Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]