This thread of discussion has elucidated many interesting points about the
value and drawbacks of both the property driven and stream oriented
modifications to a service's output. Architecturally there is no reason to
exclude one in favor of the other and discussions in the use case subgroup
have brought out cases where one would be preferred to the other. Consider:
- Need for a consumer to indicate the type of output a producer should
generate (XHTML vs WML vs ....). Much easier with a property driven
approach.
- Desire of a consumer to supply input that the producer will use when
generating its output (eg. a news service that a financial page wishes to
configure for display with an End-User's portfolio ... with the news
focussed on the portfolio items). Again easier with a property driven
approach.
- When wrapping a legacy web app, in many cases a producer can't (or
won't) modify the app to use a property driven approach. The stream
oriented adaptations then allow a robust means (as robust as the writer of
the locators that point into the stream makes them) for a consumer to do
things such as:
- lookup values the producer has imbedded in the page
- inserting related markup (such as cross-selling markup)
- inserting content that is confidential between the consumer and the
End-User
- insert the validation or action processing desired by the consumer
(eg. consider a consolidated shopping cart)
As also mentioned by others, there are times when both the Producer and the
Consumer wish to exert control over the markup (often for branding
reasons). Supporting both means of modifying the markup allow the business
entities standardized means to implement the choices made in their business
arrangement.
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.