Re: AW: AW: [sdo] ISSUE 66: Proposed Resolution, One More Attempt

[Bryan Aupperle <aupperle@us.ibm.com>]

I know that I am a bit tardy with this
reply (I'm traveling this week), but I have a couple of more thoughts on
this topic.

While it is true that C++ has instance
classes and static SDOs, the fundamental types like char, int, float, etc.
do not have instance classes, so using instance class to determine if properties
with dataType == true does not work.

Also,  if Type A has property X
which is Type URI and Type B has property X which is Type MonthDay, then
both Xs have instance class String.  I'm not sure we want to consider
A and B to be compatible (there could clearly be some strange results accessing
X after a project).

And I'll take up the initial portion
of the challenge of splitting the spec in to a core part an a Java part.
 I have no doubt that I will get some things wrong, but at least getting
something out there will allow us to discuss it.

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect

Research Triangle Park,  NC 
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

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

04/03/2008 02:19 PM

To	Bryan Aupperle/Raleigh/IBM@IBMUS, <sdo@lists.oasis-open.org>
cc
Subject	AW: AW:  [sdo] ISSUE 66:  Proposed Resolution, One More Attempt

Hi Bryan,
 
 
I understand your concern, and
have often wished that someone would refactor the spec.  Unfortunately,
the only place where DataHelper, TypeHelper, Type, etc are described is
in a chapter called "Java API".  I've started several times
to split this into a conceptual chapter (that could be applied across languages)
and a Java instanciation, but it's a very big job and I frankly don't have
the time.
 
On the otherhand, instanceCLass
is not java specific, C++ at least has instance classes and static SDOs.
 And in any case, the problem is not specific to the proposal, but
is general to the whole document.
 
Ron

---

Von: Bryan Aupperle [mailto:aupperle@us.ibm.com]
Gesendet: Mittwoch, 2. April 2008 19:36
An: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] ISSUE 66: Proposed Resolution, One More Attempt


While I am OK in concept with this, the use of instance class in compatibility
is language specific.  It would be nice if we had a clean way of referring
to the intrinsic type when DataType is true without relying on a language
specific mechanism. 

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect

Research Triangle Park,  NC 
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

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

04/02/2008 11:39 AM

To	"Frank Budinsky" <frankb@ca.ibm.com>, <sdo@lists.oasis-open.org>
cc
Subject	AW:  [sdo] ISSUE 66:  Proposed Resolution, One More Attempt

Hi Frank,

I'd be OK with this wording, assuming we also agree to revisit later, and
try to loosen up the definition of compatibility.

Can I ask for a "straw poll", to see where we are with getting
acceptance on this issue.  If you have objections, or suggestions
for modifications, please state them.

Ron

-----Ursprüngliche Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Gesendet: Mittwoch, 2. April 2008 17:01
An: sdo@lists.oasis-open.org
Betreff: [sdo] ISSUE 66: Proposed Resolution, One More Attempt

Hi Ron,

Here's one more attempt, that hopefully addresses your concerns.

Frank.

4.5.4    Compatibility Between Types
Types in different HelperContexts may represent the same underlying 
business data.  Often Types in different contexts are closely enough
related that it is possible to transfer the business data between the 
contexts using the DataHelper.project() method.  Types that are closely
enough related to allow this are termed compatible Types. 

Two DataTypes are compatible if they have the same instance class.

Two DataObject (Complex) types, T1 and T2, are considered compatible if
their definitions are identical or differ only in the following ways:

1.      T1.instanceClass != T2.instanceClass
2.      T1.name != T2.name or T1.aliasNames != T2.aliasNames,
provided 
there is a matching name in the two sets of names 
3.      Corresponding properties P1.name != P2.name or P1.aliasNames
!= 
P2.aliasNames, provided there is a matching name in the two sets of names
4.      Corresponding properties P1.containment != P2.containment

The properties in T1 and T2 need not be in the exact same order, as long
as corresponding properties can be uniquely matched in the two types 
according to the above rules.

Implementations may choose to loosen these requirements on compatibility,
for instance, an implementation may choose to allow the set of properties
in T1 to be a subset of the properties in T2.  An implementation 
definition of compatibility may not be made more restrictive.





Frank Budinsky/Toronto/IBM
04/02/2008 10:10 AM

To
sdo@lists.oasis-open.org
cc

Subject
Re: AW: [sdo] ISSUE 66:  Proposed Resolution, Second Attempt





Oops, right after hitting the "send" buttom, I noticed your point
about 
DataTypes name mismatch. Good point. How about this:

4.5.4    Compatibility Between Types
Types in different HelperContexts may represent the same underlying 
business data.  Often Types in different contexts are closely enough
related that it is possible to transfer the business data between the 
contexts using the DataHelper.project() method.  Types that are closely
enough related to allow this are termed compatible Types. 

Two DataTypes are compatible if they have the same instance class.

Two DataObject (Complex) types, T1 and T2, are considered compatible if
their definitions are identical or differ only in the following ways:

1.      T1.instanceClass != T2.instanceClass
2.      T1.name != T2.name or T1.aliasNames != T2.aliasNames,
provided 
there is a matching name in the two sets of names 
3.      Corresponding properties P1.name != P2.name or P1.aliasNames
!= 
P2.aliasNames, provided there is a matching name in the two sets of names
4.      Corresponding properties P1.containment != P2.containment

Implementations may choose to loosen these requirements on compatibility,
for instance, an implementation may choose to allow the set of properties
in T1 to be a subset of the properties in T2.  An implementation 
definition of compatibility may not be made more restrictive.

Frank.





Frank Budinsky/Toronto/IBM@IBMCA 
04/02/2008 09:55 AM

To
sdo@lists.oasis-open.org
cc

Subject
Re: AW: [sdo] ISSUE 66:  Proposed Resolution, Second Attempt






Hi Ron,

> I think we need to define what "corresponding properties"
(in point 
> 3) means.

Personally, I think it's clear because of the statement:

   "definitions are identical or differ only in the following
ways:"

Since we're talking about the delta from identical, corresponding 
properties in this case means "otherwise identical". 

Do others think this is unclear?

> I also think we need to say something about data types.

Since none of the points in the list apply to DataTypes, other than #2,
DataTypes need to be identical (except for name/aliasName). I think that's

what we want.

> However, I would also suggest saying 
> something about OpenContent properties associated with the type (or
> property) not being relevant

I'm OK with adding that, but think it may be better to cover it with "
Implementations may choose to loosen these requirements" for now,
and 
maybe add something later, when it's clear exactly what we want to 
require.

Frank.

"Barack, Ron" <ron.barack@sap.com> wrote on 04/02/2008
03:58:10 AM:

> Hi Frank,
> 
> I think we need to define what "corresponding properties"
(in point 
> 3) means.  I believe you mean that P1 and P2 "correspond"
to each 
> other if the is a match between the names.  I'm not sure how
to 
> phrase this formally, though (everytime I try I wind up talking 
> about the intersection of sets).
> 
> I also think we need to say something about data types.  I like
the 
> definition of datatypes matching iff their instance class matches.
> This allows something that's defined through java to hava a property
> of type "String" be compatible to something defined in schema,
that 
> has a property of type "URI".
> 
> Seeing that we allow the definition to be loosed, then I guess I can
> live with this proposal.  However, I would also suggest saying
> something about OpenContent properties associated with the type (or
> property) not being relevant (at least, OpenContent properties other
> than those mentioned in the spec).  Here's the use-case I'm thinking
> about.  Imagine an RDB DAS that keeps the table name associated
with
> a type in an open content property.  I would hope that the users
of 
> this DAS would have type systems that need not (indeed, should not)
> know about this OR mapping information.  The two types (on the
> client and on the DAS) should be compatible.
> 
> 
> Best Regards,
> Ron
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Frank Budinsky [mailto:frankb@ca.ibm.com] 
> Gesendet: Dienstag, 1. April 2008 23:49
> An: sdo@lists.oasis-open.org
> Betreff: Re: [sdo] ISSUE 66: Proposed Resolution, Second Attempt
> 
> Hi Ron,
> 
> Here is my suggested wording for the compatibility section. If we
don't 
> all agree on containment, then we can remove item 4 for now.
> 
> Frank.
> 
> 4.5.4    Compatibility Between Types
> Types in different HelperContexts may represent the same underlying
> business data.  Often Types in different contexts are closely
enough 
> related that it is possible to transfer the business data between
the 
> contexts using the DataHelper.project() method.  Types that are
closely 
> enough related to allow this are termed compatible Types. 
> 
> Two types, T1 and T2, are considered compatible if their definitions
are 


> identical or differ only in the following ways:
> 
> 1.      T1.instanceClass != T2.instanceClass provided
T1 and T2 are not 
> DataTypes
> 2.      T1.name != T2.name or T1.aliasNames != T2.aliasNames,
provided 
> there is a matching name in the two sets of names 
> 3.      Corresponding properties P1.name != P2.name
or P1.aliasNames != 
> P2.aliasNames, provided there is a matching name in the two sets of
names
> 4.      Corresponding properties P1.containment !=
P2.containment
> 
> Implementations may choose to loosen these requirements on 
compatibility, 
> for instance, an implementation may choose to allow the set of 
properties 
> in T1 to be a subset of the properties in T2.  An implementation
> definition of compatibility may not be made more restrictive.
> 
> 
> 
> 
> 
> "Barack, Ron" <ron.barack@sap.com> 
> 04/01/2008 01:40 PM
> 
> To
> <sdo@lists.oasis-open.org>
> cc
> 
> Subject
> [sdo] ISSUE 66:  Proposed Resolution, Second Attempt
> 
> 
> 
> 
> 
> 
> Hi Everyone,
> 
> I've tightened up the definition of compatibility. Although it doesn't
go 
> so far as to say "exactly the same except...", I think most
of the 
problem 
> cases are avoided, while still support our SCA wiring use-cases. I'd
be 
> pretty sorry to make supporting compatibility between types that have
> different containment structures a vendor extension: it's just too
> important to our JPA/DAS -> BPEL use case.
> 
> If this wording is not acceptable, let's try to do a couple of 
iterations 
> over the mailing list.
> 
> Best Regards,
> Ron
> 
> 4.5.2    Type Contents
> A Type will always have:
> Name - A String that must be unique among the Types that belong to
the 
> same URI in the same HelperContext.
> URI - The logical URI of a package or a target namespace, depending
upon 


> your perspective.
> Boolean fields indicating if the type is open, abstract, sequenced,
or a 


> data type.
> 
> A Type can have:
> Properties - a list of Property objects defined by this Type. Types
> corresponding to simple data types define no properties.
> Instance Class - the java.lang.Class used to implement the SDO Type.
> If DataType is true then a Type must have an Instance Class. Example
> classes are: java.lang.Integer and java.lang.String. 
> If DataType is false, and generated code is used, then an Instance
Class 


> is optional. Examples classes might be: PurchaseOrder and Customer.
> ˇ       Aliases - Strings containing additional names.
Alias Names must 
be 
> unique within a URI. All methods that operate on a Type by name also
> accept alias names. For example, a Type might be assigned an alias
name 
> for the domains it is used in: an XML Schema name "PurchaseOrderType",
a 


> Java name "PurchaseOrder" and a database table name "PRCHORDR".
> ˇ       Instance properties ? open content metadata
extensions attached 
to 
> the Type instance.
> 
> 4.5.3    Name Uniqueness
> Within a single HelperContext, the combination of a URI and a Type
names 


> or Type alias names uniquely identifies the type. Other HelperContexts
may 
> have different (and conflicting) definitions for types having the
same 
URI 
> and name.
> Property names and Property alias names are all unique within a Type
and 


> any base Types. 
> 4.5.4    Compatibility Between Types
> Types in different HelperContexts may represent the same underlying
> business data.  Often Types in different contexts are closely
enough 
> related that it is possible to transfer the business data between
the 
> contexts using the DataHelper.project() method.  Types that are
closely 
> enough related to allow this are termed compatible Types. 
> The following rules are used to determine compatibility.
> 1.      Two DataTypes are compatible if they have the
same instance 
class.
> 2.      A complex type T1 is compliant with a type
T2.  The types are 
> compliant if 
> a)     The URI and name of both types are equal.
> b)     Both types are concrete.
> c)     T1.isSequenced() is identical to T2.isSequenced()
> d)     T1.isOpen() is identical to T2.isOpen()
> e)     T1.isNullable() is identical to T2.isNullable()
> f)       For every property P1 in T1 there is a property
P2 in T2 such 
> that
>                    
                     
          i.     P1.getName() 
is 
> equal to P2.getName()
>                    
                     
         ii.     P1.getType() 
is 
> compatible with P2.getType()
>                    
                     
        iii.     P1.isMany() 
is 
> identical to P2.isMany()
>                    
                     
        iv. 
> XMLHelper.isXmlElement(P1) is identical to XMLHelper.isXmlElement(P2)
> g)     For every property P2 in T2, there is a property
P1 in T1 such 
that
>                    
                     
          i.     P1.getName() 
is 
> equal to P2.getName()
>                    
                     
         ii.     P1.getType() 
is 
> compatible with P2.getType()
>                    
                     
        iii.     P1.isMany() 
is 
> identical to P2.isMany()
>                    
                     
        iv. 
> XMLHelper.isXmlElement(P1) is identical to XMLHelper.isXmlElement(P2)
> 
>  Implementations may choose to loosen these requirements on 
compatibility, 
> for instance, an implementation may choose to allow the set of 
properties 
> in T1 to be a subset of the properties in T2, that is, to require
either 


> 2.f or 2.g.  An implementation definition of compatibility may
not be 
made 
> more restrictive.  In particular, the following characteristics
may not 
be 
> used in determining if types are compatible 
> 1.      The instance class (that is, the static SDO)
associated with a 
> complex type.
> 2.      Whether the value of P1.isContainment() is
identical to the 
value 
> of P2.getContainment()
> 3.      The XML or Java names of the properties.
> 4.      Any validation information (e.g., XSD facets)
associated with a 
> DataType
> 5.      The order of the properties in Type.getProperties()
> 6.      The base types associated with either of the
types.
> 7.      Whether or not properties are defined as bi-directional.
> 
________________________________________________________________________________
> 4.14.2          The Project method
> The DataHelper.project() method is used to move data between contexts.
The 
> behavior of this method is as follows.
> Consider object O1, where O1.getType() is T1 and where 
> T1.getHelperContext() is C1.  Consider a context C2 that defines
a Type, 


> T2, that is compatible to T1 according to the definition in section
4.5.4. 
>  The method
>      DataObject O2 = C2.getDataHelper().project(O1);
> returns a DataObject O2 such that 
> 1.      O2.getType() is T2
> 2.      If P1.getType().isDataType() is true then O1.get(P1)==O2.get(P2)
> 3.      If P1.getType().isDataType() is false, then
if O1.get(P1) is 
null, 
> O2.get(P2) is null, otherwise
>     O2.get(P2)==C2.project(O1.get(P1))
> If O1 and O2 are both sequenced, then the order of the elements in
the 
> sequences will match.
> If C2 does not define a type that is compatible to T1 according to
the 
> definition in section 4.5.4, the project operation MUST throw an 
> exception.
> The project operation leaves the DataObject O1, and all objects in
the 
> transitive closure reachable from O1  in an undefined state.
 O1 may be 
> returned to a defined state by reversing the project operation, i.e.,
>      C1.getDataHelper().project(O2);
> Notice that each DataObject has a single representation in each context,


> That is,
>      DataObject O2 = C2.getDataHelper().project(O1);
>      DataObject O3 = C2.getDataHelper().project(O1);
>      assertSame(O2, O3);
>      DataObject O4 = C1.getDataHelper().project(O2);
>      assertSame(O1, O4); 
> 
> The project method must assure that the object returned from a 
projection 
> is valid according to the rules defined in the context where the 
object?s 
> type is defined.  This includes restrictions derived from the
type?s 
> containment structure, e.g., there can be no objects in the containment
> graph reachable from the projected object that have more than one
> container.  For instance, consider an object P1, with Type T1,
in 
context 
> C1.  Assume that it has 2 properties, ?a? and ?b?, neither of
which are 
> marked as being a containment property.  Then it could be legal
to set 
the 
> value of these properties to the same object, N1.   Now consider
a 
second 
> type, T2, in context C2, that is compatible with T1 but in which the
> properties ?a? and ?b? are both marked as being containment properties.
> Then the DataObject P1 cannot be projected into the context C2, because
> the object N1 would project to an object that has conflicting 
containment 
> properties.
> Similarly, an implementation must check than any bi-directional 
properties 
> have consistent values.  Of course, this is automatic if the
properties 
> are bi-directional in both HelperContexts.  In the case where
the 
original 
> object does not have a bi-directional property, an implementation
must 
> check the consistency of both side of the property. 
> If the project operation would result in a datagraph that violates
the 
> restrictions imposed by the type definitions in that context, the
project 
> method MUST throw an exception.
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 
> ---------------------------------------------------------------------
> 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
> 


---------------------------------------------------------------------
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





---------------------------------------------------------------------
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


---------------------------------------------------------------------
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