[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [sdo] ISSUE 66: Proposed Resolution, Second Attempt
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]