SDO 3 Core and Optional Features

[Frank Budinsky <frankb@ca.ibm.com>]

As follow-up to the discussion we had today about possibly making some of 
the features of SDO 3 optional, the basic idea is if somebody wants to 
create an SDO implementation that only supports specific clients (use 
cases), some of the features (like the ones I listed below) may 
essentially amount to dead code, i.e., they would never be used. Ideally, 
the spec would formally acknowledge (i.e., identify) these potentially 
unneeded features. If the spec doesn't label these features as optional, 
then implementations will either need to implement the whole spec, or in 
the case where it's too much effort, simply choose to not be spec 
compliant. The latter would reduce the number of compliant SDO 
implementations which, I think, would reduce the value of the spec. Making 
parts optional would still leave them as specified compliance points, the 
only difference is that an implementation which doesn't want to compete in 
a certain application space, would not be forced to comply with those 
parts of the spec. An implementation could be described as compliant, but 
not complete. I think lowering the bar (cost of entry) for more 
application-specific tuned SDO implementations, would result in more SDO 
implementations, which would help increase SDO acceptance overall.

Here is a first pass at how IBM looks at the SDO functionality (current 
thinking anyway).

1. SDO Core Functionality - Required
     - this includes everything in the specification that is clearly 
defined and not specifically called out as one of the optional features 
below
2. Dynamic MetaData Creation - Optional
     - this is essentially the TypeHelper.define() method. It's never used 
in situations where XML Schema is always used to define MetaData.
3. XSD generation - Optional
     - in situations where XMLSchema is always used to define metadata, 
XSDHelper.generate() is uninteresting. At best it would reproduce the 
schema which the user already has, at worst it produces a different schema 
which is not really the "correct" one.
4. ChangeSummary standard serialization format - Optional
     - the spec-defined serialization format is inefficient and is only 
important if we wish to interoperate between implementations. This may be 
part of a potentially bigger interoperability feature, but other than 
ChangeSummary format, the rest of the XML structure is well defined in 
XMLSchema. As a result, it's possible for an implementation that doesn't 
support ChangeSummary interoperability to still be interoperable for any 
data graph that doesn't use ChangeSummary.
5. Some aspects of Static SDO - Optional? (maybe)
     - Not sure what the spec actually requires today. Does it require a 
static code generator? Some of the new features that we're discussing 
lately, related to annotations, JAXB, etc. - which of these things are 
required by all implementations and which may be optional features?
6. The new Key support - Optional? (maybe)
     - Is the new key support intended to support RDB scenarios, or are 
there other use cases. If it's not really applicable to XSD-based models, 
an XML focused implementation won't require it - it would never be used.