[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]