Re: [regrep] Groups - regrep-modules.pdf uploaded

["Carl Mattocks" <carlmattocks@checkmi.com>]

+1 on proposed extensions making use of XML Schema (extensions ?)

<quote who="Farrukh Najmi">
> 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
>>>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 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
-- 
Carl Mattocks

co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC
co-Chair OASIS Business Centric Methodology TC
CEO CHECKMi
v/f (usa) 908 322 8715
www.CHECKMi.com
Semantically Smart Compendiums
(AOL) IM CarlCHECKMi