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.

Editors

Please coordinate with editors rather than modifying thispage directly.

Description

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.

Current Alternatives

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.

Rationale

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.

Tactics

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.

Use Cases

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:

Farid is impressed with how extensible ebXML Registry standard is. He reccommends it to his friends and is happy again :)

Decisions

The following decisions reflect current thinking.

Proposed Decisions

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.

Specification

TBD

documents/proposals/typeExtensibility (last edited 2009-08-12 18:05:08 by localhost)