Re: Some items for discussion (Issue 8: Conflict Resolution Rules)

Joel, wrote on 05/11/2006 04:12:01 PM:

> Rama,
> I agree that we should add rigor and clarity to the resolution rules. If
> you have some possible suggestions, please send them along.

One possible suggestion - which I have already made,  is to design things
in such a way that conflicts don't arise at all. Let me explain below.

> I don't think we can eliminate the need for these rules since there are
valid reasons for
> putting annotations at both levels.

May be we can eliminate the need for these rules after all if we don't
provide multiple ways of annotating the complex type. For example in the
current spec under the heading 'Annotating Complex types' we say that the
reason why leaf level annotations are not enough is because this approach
assumes one-to-one correspondence between the schema elements and the
concepts in the domain model and that may not be the case if we want to
support one-to-many and many-to-one mappings. If we think about this,
One-to-many can be supported as is because we are going to support adding
multiple annotations to the same element via list. With regards to
many-to-one mappings, we introduced this primarily to support XSLT type of
mappings where we can say 'first name' and 'last name' elements in this
WSDL concatenated together matches 'name' concept in that domain model. But
in Issue 6 'Clarification of SchemaMapping concept', I raised this point
that we probably should only focus on schema mapping in SAWSDL - not data
mapping. If that is the case, then, many-to-one mappings can be dealt with
via leaf annotations. Because if we don't care about how the data values
get mapped then in the first name and last name example, at SAWSDL level,
both 'first name' and 'last name' will have 'name' concept as the semantic
annotation. This should work fine if we really mean these annotations to be
annotations at semantic level but not at data level.  If we go with this
approach, we would essentially be not making any distinction between simple
types and complex types in the spec  - which I believe is also the point
Laurent raised in his issue # 11. Then the conflict resolution rules can be
avoided altogether because there would not be any conflicts.

> I am unaware of a way to enforce the
> rules.  The schema will not help here and we don't have much else at our
> disposal.
> > Item: Conflict Resolution Rules (at the bottom of the section 2 in the
> > spec):
> > At the bottom of the section 2, we specify a bunch of rules to resolve
> > conflicts. Is there a way to formalize these rules or enforce them via
> the
> > spec? Or may be we should think about designing things in such a way
> > conflicts don’t arise at all.
> Regards,
> Joel

Rama Akkiraju

Received on Thursday, 11 May 2006 23:13:24 UTC