sdo message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: AW: AW: [sdo] ISSUE 66: Proposed Resolution, One More Attempt
- From: "Barack, Ron" <ron.barack@sap.com>
- To: "Bryan Aupperle" <aupperle@us.ibm.com>, <sdo@lists.oasis-open.org>
- Date: Thu, 3 Apr 2008 20:19:08 +0200
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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]