[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia] RE: Questions regarding embedded and customized-integratedusecases
Hi All, I think Stefan has captured my concern very well, I had assumed that the use cases model and map to real world scenarios, rather than just buckets to capture all requirements with somewhat arbitrary boundaries. The point of confusion I still have is that during the call a comment was made that "look & feel was orthogonal to all use cases", this was re-enforced in Rex's recent email as well. Whilst I agree that look & feel could in general be considered a consumer issue and common to all use cases, it needs to be captured somewhere and understood. The emails thus far appear to favor using the embedded use case as the LCD, including consumer flows. Regards Greg -----Original Message----- From: Beck, Stefan [mailto:stefan.beck@sap.com] Sent: Sunday, March 17, 2002 10:55 AM To: wsia@lists.oasis-open.org Subject: RE: [wsia] RE: Questions regarding embedded and customized-integr ated usecases Hi All, from a technical perspective, the embedded use case is the LCD. But from my point of view as representative of an application vendor, such a Web Service integration without adaptations of the look and feel is rather theoretically and won't be really used. These adaptations would be a minimal requirement from our customers. I did not participate as you started with the use cases. So when the main issue of the use cases is to cover all technical features, I would say it is ok using embedded as LCD. Otherwise, when it should be something like minimal requirements, we should add some issues from customized. Stefan -----Original Message----- From: Eilon Reshef [mailto:eilon.reshef@webcollage.com] Sent: Samstag, 16. März 2002 19:31 To: griddell@bowstreet.com; wsia@lists.oasis-open.org Subject: Re: [wsia] RE: Questions regarding embedded and customized-integrated useca ses I find This discussion extremely interesting, as it clearly brings up the point that what might be the LCD from a technical perspective (URL rewriting + lifecycle management) might not align with the requirements for portlets, which seem to span additional functionality (and I do believe that further discussions will reveal many more requirements for WSRP such as administration, user management, etc.). -----Original Message----- From: Graeme Riddell <griddell@bowstreet.com> Date: Sat, 16 Mar 2002 12:23:33 To: Wsia <wsia@lists.oasis-open.org> Subject: [wsia] RE: Questions regarding embedded and customized-integrated use ca ses 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> ---------------------------------------------------------------- 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