Type Extensibility Overview
Nothing in this page is etched in stone. This page decsribes a new proposed feature for a future version of the core ebXML Registry specifications.
Please coordinate with editors rather than modifying thispage directly.
- Farrukh Najmi
- Nikola Stojanovic
Type extensibility feature enables an ebXML Registry profile specification to specify new classes as extension of ebRIM. These new classes are first-class classes and have all the rights, privileges and treatement within the registry that pre-defined ebRIM classes enjoy.
Specifically, the Type Extensibility specification defines how to extend the core ebXML Registry XML Schema, SQL Schema, the ebRS protocol (if needed) for supporting the new types.
We currently 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.
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.The feedback from profile developers is that "soft" type extensibility is inconvenient, less flexible and less efficient. They are requesting the need for first-class Type Extensibility that is being proposed here.
It is expected 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.
We collaboratively define the Type Extensibility spec on this wiki page. Implementations of ebXML Registry such as Goran's registry and freebXML Registry may choose on their own volition to implement the draft 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 this wiki page 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.
Actor: Profile Spec Author
Farid, is an author of "ebXML Registry Profile for Geneology Data". This profile specifies how to use extension features of ebXML Registry to specialize it so it can be used to store geneology information in form of interlinked family trees. Farid wishes to define an Object Oriented information model called the Person Information Model (PIM) which has classes such as Person, LifeEvent, BirthEvent, DeathEvent, MarriageEvent, Location etc. Farid reads the ebXML Registry Tutorial and finds that he can map his PIM to ebRIM using ExtensibleObjects, ObjectTypes and Slots. Much to his suprise the mapping is alread described in the ebXML Registry Tutorial
However, Farid find that he has much less flexibility and control when defining a new type. He can only extend ExtrinsicObject. Also the extended class cannot have any first-class attributes. Only simple key-value pairs called Slots. There is no way to enforce the presence of specific types of slots on instances of a specific extension type. Queries that predicate on extnsion attributes modeled as slots seem un-natural. All this makes Farid very unahppy
Farid then discovers that the ebXML Registry specs also provide a way to add new first-class types as extension of ebXRIM types! He is delighted because now he can do a direct mapping from PIM to an extended ebRIM by adding new first-class classes named Person, LifeEvent, BirthEvent, DeathEvent, MarriageEvent, Location etc. He finds that he can define first class attributes on these classes. For example, BirthEvent has attribute:
- timestamp dateOfBirth
- Location placeOfBirth
Farid is impressed with how extensible ebXML Registry standard is. He reccommends it to his friends and is happy again
The following decisions reflect current thinking.
New classes MUST be derived from RegistryObject either directly or indirectly. The only exception are classes that are only used as composed objects within a new class that is derived from RegistryObject.
- New classes MUST have SQL Schema, XML Schema bindings defined following mapping patterns consistent with mapping of core RIM classes to Schema, XML Schema.
Please add proposed decisions here for broader discussion as bullets or add your comments (along with your name) as sub-bullets to existing bullets. Over time Proposed Decisions wioll be moved to Decisions section if there is broad agreement.
- XML Schema binding for extension classes MUST be in a different file than rim.xsd and it MUST import rim.xsd (Farrukh)
- XML Schema binding for extension classes MUST be in a different namespace than the rim namespae (Farrukh)
- Canonical Parameterized queries may be defined by extension / profile specification to make use of attributes and elements in the extension classes