Fwd: [wsia] RE: Questions regarding embedded and customized-integrateduse ca ses

[Rex Brooks <rexb@starbourne.com>]

Title: Fwd: [wsia] RE: Questions regarding embedded and custo

Date: Sat, 16 Mar 2002 13:45:32 -0800
To: Graeme Riddell <griddell@bowstreet.com>
From: Rex Brooks <rexb@starbourne.com>
Subject: [wsia] RE: Questions regarding embedded and customized-integrated use  ca        ses
Cc:
Bcc:
X-Attachments:

> I guess where I'm losing track of strict
> definitions is in what constitutes a modification. I had thought of
> embedded as a use-case where the portal takes the data and/or textual
> information as is, and inserts or embeds it directly into an available
> display widget/slot in the portal without need for change of any
> kind.
>
> I'm not sure where the discussion of look
> and feel came from with regard to this. I was seeing this as data and
> text without presentation parameters. I thought that the WSIA Producer
> in this case doesn't have to bother with that stuff, just shoots the
> info down the pipe. And, likewise the Producer just produces what is
> asked for, via the request context info presented by the Consumer on
> behalf of the End User.
>
> Of course, I assumed that the lookup
> portion of the request sequence (UDDI or an added supplementary WSIA
> repository function added to that lookup) takes care of specifying
> what packages of info/data can be served up by a given WSIA Producer,
> so that this was not a case of asking for customized portlet packages,
> just choosing from available packages.
>
> That what I thought. The only reference
> to display in Rich's use-case is the last bullet of 3.1.1 "*
> Markup type configured by the Consumer at page load time based on
> End-User profile or device type in use by End-User."
>
> I know we talked about it briefly in the
> meeting, and I just checked the minutes. What I got from the meeting
> was the idea is that while the issue of look and feel, like
> republishing and permissions/rights as part of a contract or WSLA
> (License Agreement?), is orthogonal to all use cases, it is dealt with
> more precisely within the Customized Use Case.
>
> So I guess I agree.
>
> I vote yes to line numbers and a standard
> Number for Requirements. Rich's Embedded Use Case is the only one that
> included it as Number 7. That's also fine with me.
>
>
> > That seems to be a great answer - so WSRP
> > might actually span both Embedded
> > and Customized, and for the purpose of that committee might "own"
> > some
> > "low-end" Customized functionality and drill down on that,
> > and rely on WSIA
> > for the LCD Embedded. WSIA would then also own "higher-end"
> > Customized
> > functionality that WSRP would be less concerned about?
> >
> > -gr
> >
> >
> > -----Original Message-----
> > From: Jeff Broberg [mailto:jbroberg@silverstream.com]
> > Sent: Saturday, March 16, 2002 12:19 PM
> > To: Graeme Riddell; Wsia
> > Subject: RE: [wsia] RE: Questions regarding embedded and
> > customized-integrated use ca ses
> >
> >
> >
> >
> > (In fact this makes me wonder if WSRP is actually aligned with
> > Embedded or
> > whether it is a "low-end" version of Customized).
> >
> > >>> i believe it is more aligned with Customized, but the
> > minimal
> > requirement should still be Embedded, and we should try and coordinate
> > with
> > WSRP so that they also have the same view on what minimal is.
> >
> > :-) jcb
> >
> >
> >
> > -----Original Message-----
> > From: Greg Giles [mailto:ggiles@cisco.com]
> > Sent: Friday, March 15, 2002 11:55 PM
> > To: Wsia
> > Subject: [wsia] Questions regarding embedded and
> > customized-integrated
> > use cases
> >
> >
> > Hi All,
> > In today's con-call I raised two separate but related points that need
> > to be
> > discussed further. I'll start be restating the points followed by
> > a
> > recommendation
> >
> > 1. For the embedded use case there is no mention of the modification
> > that
> > can be done by the consumer, other than URL rewriting. However
> > this
> > requirement seems key in the travelers check portal use case given,
> > there
> > are several scenarios to consider, here are two:
> >
> > - The portal (consumer) may want to modify the look and feel, e.g..
> > color &
> > logo to match conform to the site branding. This is different to the
> > look &
> > feel modification mentioned in the spec which is per user
> > - In the travelers check use case the producer may show an email
> > address or
> > phone number to contact for further info,
> > within corporations its typical to
> > have a dedicated contact, and they would need to change this
> >
> > Both of these could be done by the consumer, without requiring changes
> > to
> > the producer and are classic stream
> > modification requirements.
> >
> > 2. In the customized producer use case there are several sections
> > e.g.
> > 3.2.7, 3.2.9 .. that refer to consumer modification. Whilst they
> > are
> > valuable and complete use case, they are not unique to the use
> > case.
> > The statement in the use-case "The Customized Producer use case
> > extends the
> > Embedded use case" implies that the embedded use case does not
> > support or
> > require consumer modification, my previous point demonstrates this is
> > not
> > true
> >
> > Recommendation:
> > There are two potential solutions:
> >
> > 1. Accept the embedded use case is a subset of all use case and move
> > the
> > common consumer based alternate flows to the embedded use case
> >
> > 2. Construct a separate document of consumer based alternate flows
> > (Charlie's suggestion from the con. call) and refer to the document
> > sections
> > from the use case
> >
> > I would tend to prefer option 2. since the embedded use case may not
> > be a
> > subset of all others, but I haven't dissected the other use-cases
> > to
> > validate this.
> >
> >
> > Two closing points:
> > - I personally find it useful to have line numbers on each document,
> > during
> > our email discussions we can refer to explicit line numbers. This
> > feature is
> > easy to turn on in M. word. Any votes for / against?
> > - Within the embedded and customized-integrated use cases the
> > actor
> > 'producer' is defined as "one or more WSIA web services".
> > This is different
> > to our glossary definition of producer - "A business entity that
> > hosts a Web
> > service or a Web site". I would vote for changing the glossary
> > definition.
> >
> > Have a good weekend
> > Greg
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
> -- 
>

--