AW: [sdo] ISSUE 66: Proposed Resolution

["Barack, Ron" <ron.barack@sap.com>]

Title: ISSUE 66: Proposed Resolution

Hi,

 

The discussion on sequenced data objects and the project operation is getting a little complex.  In an effort to try to frame the discussion, let me try to take a step back, and pose a few fundamental questions, and discuss their consequences as I see them.

 

The first question is "is the sequence part of the underlying data (like the values of properties), or is it part of the view (like containment)?".

 

Considering the sequence to be part of the underlying data simplifies our world a quite a bit, since in this case we don't have to worry about any of the four cases that Stefan describes in his email.  It also restricts our use-cases.

 

If we consider the sequence to be part of the view, then we give users the ability to use the same underlying data to generate XML that validates against different schemas.  The "industrial standard" schemas that Frank likes to talk about tend to be complex enough that the user has no chance of creating valid documents without manipulating the sequence.   Do we really want to say that the data objects that make up these documents can never be casted POJOs (eg, to JPAs)?

 

If we take the complex but flexible approach of saying that the sequence is part of the view, not of the data, then we need to identify what is the initial state of the sequence after the project operation.  At least for the case that O2 is a new projection (that is, we are casting into a new context rather than "casting back" into an old one), at least the first 3 rules that Stefan gives seem to be pretty clear and logical.  The problem comes, really, during a cast back into the original context.

 

The next basic question about sequenced data objects is "does the sequence survive the cast operation"?  In Stefan's proposal, the sequence does not survive.  If it does survive, then we start getting questions about how changes made to O2 effect the sequence of O1.   The most obvious approach here is to say that when setters are called on O2, the O1's sequence is modified just as if the corresponding setter were called on O1.  But as soon as we start dealing with the methods that directly manipulate the sequence (eg, add and delete), things start getting really messy.

 

I'm very interested in the groups opinion on these issues.  It's the old tradeoff, does the functionality justify the extra complexity.  I will put this discussion on Tuesday's agenda.

 

Best Regards,

Ron

 

 

 

---

Von: Buennig, Stefan [mailto:stefan.buennig@sap.com]
Gesendet: Freitag, 28. März 2008 10:35
An: sdo@lists.oasis-open.org
Betreff: AW: [sdo] ISSUE 66: Proposed Resolution

Hi Blaise,

 

We want to add our thoughts: 

 

- Sequenced Data Objects

If we imagine, the data of a DataObject are just the content of the properties and the sequence is part of the view in the specific projection then we could define the following quite simple rules:

If O1.getType().isSequenced()==false and O2.getType.isSequenced()==false, then just the content of the properties is important.

 

If O1.getType().isSequenced()==true and O2.getType.isSequenced()==false, then just the content of the properties is important. (The original sequence is lost after projection, if there is no further magic.)

 

If O1.getType().isSequenced()==false and O2.getType.isSequenced()==true, then the sequence of O2 has the default order of the properties in Type2.

 

If O1.getType().isSequenced()==true and O2.getType.isSequenced()==true, then we could define an algorithm that calculates the sequence in O2 after the projection, e.g.

Copy all properties that are elements in both types from sequence1 to sequence2 in the order that is defined in sequence1.

Append all remaining element properties of Type2 (that are attributes in Type1) in the default order to sequence2.

 

- Abstract Types

Agree, an abstract type in the target HelperContext would prevent the project operation. In detail that means a target type cannot be abstract and the original type cannot be abstract too.

 

- Open Types

It depends on whether we  will allow hiding of properties. All open content of a O1 with (O1.getType().isOpen() == true) could be hidden in O2 with (O1.getType().isOpen() == false).

 

- Undefined State 

The user should be able to determine if the DataObject is in an undefined state.

 

Best regards,

Ulf & Stefan.

---

Von: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Gesendet: Montag, 24. März 2008 16:28
An: Barack, Ron; sdo@lists.oasis-open.org
Betreff: Re: [sdo] ISSUE 66: Proposed Resolution

Hi Ron,

 

Could you clarify the following issues as they relate to the project operation below?

 

DataObject O2 = C2.getDataHelper().project(O1);

 

Sequenced Data Objects

• If O1.getType().isSequenced()==true and O2.getType.isSequenced()==false (allowed in section 4.5.4), then what is the impact on O1's Sequence as operations are performed on O2?
• If O1.getType().isSequenced()==true and O2.getType.isSequenced()==true, then are modifications made to O2's Sequence reflected on O1's Sequence?  Does this include text values O2.getSequence().addText("foo")?  What is the impact if type Types are not in agreement about which properties correspond to XML elements (included in Sequence) and XML Attributes (not included in Sequence).

Abstract Types

• Section 4.5.5 indicates that isAbstract() cannot be used in the determination of Type compatibility.  If the Type in the target HelperContext is abstract won't this prevent the appropriate target DataObject from being instantiated?

Open Types

• Section 4.5.5 indicates that isOpen() cannot be used in the determination of Type compatibility.  If the open nature of the Type does not agree then won't the presence of open content properties on O1 prevent it from being cased to O2 (O2.getType.isOpen()==false)?

Undefined State

• What does it mean for O1 to be in an "undefined state" after it is casted into C2.  Does this mean making calls to O1 will throw exceptions?  Can a programmer determine that O1 is in an "undefined state" state?

Valid DataObjects Returned

• The last 2 paragraphs of section 4.14.2 state that O2 must be valid according to the rules of C2 or an exception MUST be thrown.  What is the definition of "valid"?  With the current type compatibility definition is it possible to achieve a reasonable number of "valid" projections.  If an exception is thrown because the projected DataObject is not valid is it possible to provide the user with enough information to fix the problem.  This isn't such a concern for the initial projection, but is a concern when trying to reverse the projection to put O1 back in a "defined" state.

-Blaise

 

----- Original Message -----

From: Barack, Ron

To: sdo@lists.oasis-open.org

Sent: Thursday, March 20, 2008 9:52 AM

Subject: [sdo] ISSUE 66: Proposed Resolution

<<ISSUE 66 Proposed Resolution.doc>>
Hi Everyone,

I've removed references to POJO objects. 

Ron

---

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