Type Extensibility feature

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

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


begin:vcard
fn:Farrukh Najmi
n:Najmi;Farrukh
email;internet:farrukh.najmi@sun.com
tel;work:781-442-9017
url:http://ebxmlrr.sourceforge.net/tmp/farrukhRacePointIcon.jpg
version:2.1
end:vcard