OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [wsia] RE: Questions regarding embedded and customized-integrated useca ses

My feeling would be that we should keep the Embedded case as the Lowest
Common Denominator, recognize it to be a subset of Customized, and shift
discussions of common functionality from Customized into Embedded.

I think 2 key points to recognize/remember are:
1. that the Embedded and Customized cases are producer-focused
2. that we will be recommending the Embedded case as the minimum amount of
work that a producer of interactive content will have to do in order for his
service to be consumeable by a WSIA consumer

So I agree with Greg's points - but it's probably open to debate "what is
the LCD that the industry will be happy with?". For example, if the minimum
task defined for the WSIA-producer-wannabe is "wrap your URLs with these
tags so we can identify them and do rewriting" then that might be enough to
get a fairly ugly site up and running. But some may disagree with that as
being the minimal set - maybe background colors and fonts and stylesheets
will need tagging in order that the consumer can  turn that ugly site into a
pretty one - but that has just added to the minimal effort required to be a

(In fact this makes me wonder if WSRP is actually aligned with Embedded or
whether it is a "low-end" version of Customized).

So I agree with Greg's observations, but would favour his option (1) and
make Embedded a recognized subset of Customized, and let this lead to a
discussion of what we feel is the minimum.

:-) gr

-----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

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

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

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