Re: AW: [sdo] SDO 3 Core and Optional Features

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

Hi Ron,

I understand your position. Don't get me wrong, my list of what should be 
optional was not meant to be a concrete proposal, but rather just a way to 
explain what features of SDO are uninteresting in the IBM use case. I'm 
sure that for other use cases, the optional parts are very different. 
Ideally, I would like to see the same kind of breakdown for all the major 
use cases, after which some common uninteresting parts might emerge. I 
recognize that even if we did something like this, there's a fine line 
after which the core becomes meaningless. If we wanted to do this, we'd 
need to try to identify just some big hitters that can be optional (e.g., 
dynamic metadata creation), and like you said, everyone is still going to 
need to implement some things that they don't really care about, for the 
good of the spec.

Frank.




"Barack, Ron" <ron.barack@sap.com> 
02/20/2009 04:37 AM

To
Frank Budinsky/Toronto/IBM@IBMCA, <sdo@lists.oasis-open.org>
cc

Subject
AW: [sdo] SDO 3 Core and Optional Features






Hi Frank,

I'm all for providing a means for users to allow users to enable and 
disable features based on the their scenario, especially when such 
features impact performance.  But I strongly disagree with the approach 
you are suggesting.

The value of the spec has nothing to do with how many implementations it 
has, the value of the spec is that it provides source code compatibility 
and or interoperability between implementations.  The point of the spec is 
so that (potential) users will know what "SDO Complient" means.  A matrix 
of features that may or may not be supported does nothing to strengthen 
this.

Each of us have different usecases in mind.  DataDirect cares deeply about 
using SDO with a DAS, SAP about using SDO as a data representation in SOA, 
IBM about SDO as a dynamic API for dealing with XML.  How are we going to 
decide which of these is "core"?  In your mail, you make everything 
optional that is not involved with using SDO as a dynamic API for XML.  It 
seems like you are arguing that your use case "core" and everyone else's 
"optional".  But SDO is not a dynamic API for XML, SDO is a data 
representation that is independent of the data source.

Everyone who has implemented a spec has implemented pieces of the spec 
that they did not believe (at the time) to be relevant.  The good news is 
that often use cases come once the implementation offers them, at least 
that's my experience.  In fact, this is part of the benefit of 
implementing a spec rather than simply designing something proprietary, 
that it takes into account use cases that maybe you haven't seen yet, but 
will come, eventually.

In the particular case of change summary XML serialization, I think we all 
agree that the current format is verbose and awkward.  If you have another 
approach, please come forward with it. 

That said, there may be aspects of the 2.1 spec that can be left out of 
3.0, or left as vendor extensions.  I was arguing in yesterday's meeting 
that standard java.io Serialization may be one such feature.  But I think 
we should be aware that with each such decision we are *weakening* the 
spec, not strengthing it, which is why we agreed to try to fix 
serialization to make it something to which SAP can also sign up. 


Ron


 

-----Urspr�ngliche Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Gesendet: Donnerstag, 19. Februar 2009 23:29
An: sdo@lists.oasis-open.org
Betreff: [sdo] SDO 3 Core and Optional Features

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.


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php