As Eilon said, the use case group discussed different options for achieving
a consumer task and found that by and large many of the tasks can be
achieved via multiple ways and under some conditions (technical or
business) one option may be better or the only possible route. Since we
cannot predict the conditions the use case reports are being worked on
reflect the multi-option approach. The current drafts of the customized and
the coordinated use case reports reflect this sentiment.
regards,
Ravi Konuru
eBusiness Tools and Frameworks, IBM Research
office: 914-784-7180, tieline 8-863-7180; fax -3804
Eilon Reshef
<eilon.reshef@webc To: "'Sean Fitts'" <sean@crossweave.com>
ollage.com> cc: wsia@lists.oasis-open.org
Subject: RE: [wsia] Can a producer make look & feel changes?
03/19/2002 11:27
PM
> Just to clarify my earlier description with regards to your point below.
The Consumer physically has access to the entire markup fragment, so when
business arrangements permit, the Consumer can make any type of
modifications to the markup. I guess one of the ideas we are trying to
capture in the Customized scenario and in WSIA in general is an explicit
well-defined interface that declares what are the customization options
(and, possibly, and also arguably, how to implement them). The existence of
such an interface (independently of the mechanism that's used to describe
it) is implicitly assumed in many of the discussions, mainly for robustness
reasons (the Producer is committed to support those adaptation points one
way or another along application changes). Naturally, the interface can't
capture all of the different customization options possible, only those
predicted and supported by the Producer. It is then up to the business
arrangements to define whether adaptations other than those defined in the
WSIA interface are allowed (in which case the Consumer can freely play
around with the markup), disallowed (in which case the Consumer can't do
anything with the markup), or anything in between (e.g., allowed after a
review by the Producer). I wouldn't suppose we - as a committee - can
decide between those options; we can only come up with the interfaces and
assume the business arrangements are taken care of.
Hope that makes sense.
Lastly, on the issue of property driven adaptation vs. markup driven
adaptation, I wasn't present at the smaller group discussion, so I
may be
covering old ground. However, I have significant concerns about the
property
driven approach that extend beyond back-compatibility. To me, the
property
driven approach implies that the producer must predict all of the
changes that
a consumer may want to make (since they are responsible for
implementing
them). This may seem attractive from a Producer control standpoint
(which
I agree is an important issue), but I think it will have the effect
of limiting the
re-use of services. Certainly our experience to date suggests that
it is very
hard, if not impossible to predict the ways in which Consumers may
want to
adapt services and so I would argue we should err on the side of
flexibility.