MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Fwd: [wsia] RE: Questions regarding embedded and customized-integrateduse ca ses
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
cases
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>
--
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC