RE: [regrep] Type Extensibility feature

["Breininger, Kathryn R" <kathryn.r.breininger@boeing.com>]

I will add it to the agenda.  Note that spec work would need to be done
on the OASIS wiki. 



Kathryn Breininger
Boeing Library Services
425-965-0182 phone




-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] 
Sent: Wednesday, February 15, 2006 1:49 PM
To: regrep@lists.oasis-open.org
Cc: Goran Zugic; Nikola Stojanovic
Subject: [regrep] Type Extensibility feature


Dear colleagues,

Recently, Goran, Nikola and I have been discussing an old item on our
feature road map which is named "Type Extensibility".

As our specs are being used by more and more organizations and
verticals, and as we are seeing more and more profiles of our specs
being created, we are also seeing more and more need for this "Type
Extensibility" feature in our various deployment projects.

Type extensibility would be a new feature in a future version of the
*core* specs. It would specify the precise steps by which a profile
could define entirely new first-class types as extensions to the core
types defined by ebRIM. Such a new "first-class" type would have all the
capabilities available to pre-defined core ebRIM types. The steps will
likely define how to extend the XML Schema, the SQL Schema, the ebRS
protocol (if needed) and any other considerations.

Recall, that we already have "soft" type extensibility through
sub-classing ExtrinsicObject type augmented by Attribute extensibility
provided by the Slot type. This very simple and elegant type/attribute
extensibility has been tested by many deployments now and is quite
robust. However, it is our experience that this "soft" type
extensibility is less direct and more cumbersome that "true" type
extensibility being proposed here.

I believe that the Type Extensibility feature will become one of our
most powerful and valued extensibility feature and will be the basis for
most profiles of ebXML Registry specifications in future.

What I would like to propose is that we start work on defining the spec
for type extensibility in a collaborative manner on a wiki page in our
wiki.
Implementations such as Goran's registry and freebXML Registry may
choose on their own volition to implement the draft informal spec and
feed back their implementation experience into the wiki based draft spec
for the feature. When we feel we have reached enough maturity in the
draft spec we can decide to rev our core specs (where this draft spec
would belong) and go through the normal OASIS standardization process.
Note that the wiki page under this proposal serves as a similar role
that our draft proposal documents in the past. The main difference is
that wiki pages are more suited for living documents that are being
developed collaboratively.

Kathryn, may I request that we place this discussion on Type
Extensibility feature proposal as an agenda item for tomorrow's meeting.
Thanks in advance for your consideration.

--
Regards,
Farrukh