OASIS Web Services Component Model (WSCM) TC

OASIS Web Services Component Model
Technical Committee

7th - 9th January 2002
face-to-face kickoff meeting
IBM Research, Hawthorne, NY

Minutes, January 7th

Attendance at roll call, 9:15 Jan 7th

Duration

9.00am - 5:30pm

Chair

Charles Wiecha

Agenda for 7th Jan

Day's activities:

9:40 Election of officials

Secretary - Graeme Riddell, Bowstreet
Webmaster - John Kneiling

Regarding TC discussion list - should be open only to TC members or open to all OASIS members?
Agreed that it should be open to all OASIS members.

Voting procedures - agreed to allow voting by email rather than restricting to face-to-face or teleconf.

Action - deferred decision of who is TC editor until we understand the subcommittee breakout.

9:50 Review of charter

Web services stack evolution to date oriented towards backend, not interactive. Non web service solutions for UI exist. Portals exemplify machine-machine example of need. Driven from business perspective by the need for multiple distribution channels - no technology/standard to facilitate that today. Portlets tend to be separate apps with no knowledge of each other. Aim to describe the portlet inputs/outputs/events to give a richer composition and richer end user experience. Leverage and incorporate models emerging on flow and end point description languages.

Q: Is there a human to machine, machine to machine difference?
A: The UI construction is not just composition of presentation. Value can be added by standardizing the synchronization of web services.

Q: Name of the TC "component" implies other things like J2EE etc?
A: Want to look at this and may need to clarify that name, emphasize for "interactive applications".

Q: Procurement system assumes end user is a machine, not a human.
A: That's been the focus up to now, TC aim is to address the interactive experience. Danger in being able to deliver everything if the scope is too broad.

Q: "Component model for Interactive applications" does not say "human". XForms is moving towards machine-machine, should we leave "human" out?
A: Probably no - aiming for human interaction. Focusing on user experience, the human-facing "last-mile". Need to consider new name, perhaps "Web Services for Interactve Applications", "Web Services for Experience", "Web Services for User Interface".

Other thoughts on naming:
1. maybe keep WSCM as it implies this is a subset of something bigger
2. "enables businesses to distribute apps through new channels" -bit jargony, not specific enough.

Concept of aggregation of web services - need to define if that is part of scope. Subcommittees might be split out along lines of coarse-grain (sequential flow of web services) vs fine-grain (synchronizing and messaging within pages).

Q: changing names may cause problems?
A: Actually it might be a positive thing in feeding a more precise definition to the analyst community.

Q: "Web Services for Interactive Applications" doesn't convey it's a model we're defining so maybe "Web Services Interactive Framework" or "Web Services Interactive Model".

[bullet 2 of charter]
Need to describe the nature of our liaisons with other committees. TJ is on XForms TC, Rex is on HML and w3c member.

[output markup neutral]
Don't want to define another widget set or markup. This infrastructure needs to sit on HTML, WML, XForms, etc,

Q: What about formats that have nothing to do with markup (eg, Flash, applets) - are we forcing XML output?
A: Need to consider alternative output formats. Maybe recast as "output representation neutral".

Q: Do we want to mention I18N?
A: Goal should be "human language independent" or "content delivery independent".

Need to consider from the outset routes to market, adoption issues, don't want big pain in adoption of WSCM-recommendations and must consider various users and their adoption path.

10.45 - review of phases

Other piece of charter is proposal for phasing WSCM. First phase should be to pull in Use Cases. Think of base services as coarse grained and tie in with OASIS Web Services for Remote Portals. Need to synchronize our work with theirs. View stack picture and recognize stuff we rest on is not fixed, it's evolving too. Note WSFL allows composition as well as sequencing.

10:55 Presentation of WSXL

IBM's perspective. Concentrating on the user experience and the difference channels that the service provider might want to serve.

Allow an integrator to bring interactive UI parts together the same way as web services. If we give some expression/standard for presentation we can do a lot, provide a richer experience.

"Experience integration" - convert existing web apps to interoperable services.

Should change "getMarkup" interface of base component to "getOutput".

• Can wire component pieces together based on what provider exposes via WSDL.
• Large datasets - application responsibility (in view of WSXL)

Aim of committee is standardizing but need to be wary of standardizing too soon - should maybe recommend usage patterns and design patterns first before standardizing something.

Discussion of caching - might lead to subcommittee investigating.

[lunch]

12:30 WSUI

WSUI designed to address multiple channels, might be more appropriate to WSRP. WSUI specifies XML description of a component with action definitions and ultimately apply XSLT to construct the view.

Diffs between WSUI and the aims of WSCM:

• does not aim to leverage WSFL and XForms
• simple - reference implementation took only a week
• focus on display - does not embed html tags but higher level tags and stylesheet classes

Q: How sophisticated are any deployed apps?
A: Reference implementation and a few customers using it. The security model needs to be addressed, a customer using it for directory services plugged into portal.

Q: WSUI component is a web service?
A: It has its own WSDL, the actions appear as operations on the porttype in the WSDL.

Epicentric to provide the WSDL of the more complex example showing the actions. (Possibly a WSFL overlap here).

Q: Only targeting SOAP, HTTP?
A: No, rides on WSDL which supports many bindings to the port types.

13:15 WebCollage

No presentation yet, probably will be soon. Key requirements:

• easy for container (no model or controller)
• customizable presentation
• loose coupling, eg add Euro travellers checks in service provider without altering consumer

Q: How does latter relate to versioning?
A: In this case there was not another version, but if output really changed there could have been.

Typical customer needs:

• Service provider wanted total control over look and feel when consumed
• needed to leverage existing apps, the web interface tightly bound to legacy apps, so maybe cannot enforce a particular programming model.

Tech requirements:

• relate to traditional programming models (activeX, openDoc) eg in properties, events
• facilitate drag and drop programming, define required metadata and semantics
• facilitate coarse grained interfaces - performance, support distributed apps over a WAN

Embedded output - events must be routed via the container.

Q: Can the container act as a filter?
A: Yes, value add potential there.

Q: How about non UI based (eg Flash).
A: The model of action and data may well still apply.

Q: Increasingly get asked for non page-to-page apps/applets. WSXL event processing might imply performance penalties and scalability issues.

Q: State?
A: Is handled by cookies and URL-rewrites.

Q: Within page structure. Formal typing - we can do it with data (w3c Schema) but not so clear on presentation description, eg to give a way to splice other data into it.
A: Not in scope for what WebCollage have done so far. Responsibility is delegated to the app provider. That's consistent with WSXL Adaptation.

14:00 Crossweave

Q: Should apps create an XML interface?
A: If there's a requirement to do that it should be easy on both the container and supplier side. Consumer should be able to do it without supplier doing anything. Facilitate a pull strategy as well as a push strategy.

UI composition, service composition, service adaptation rests on authentication, transactions, sessions and service proxying.

Q: Other people addressing these issues?
A: Primarily BTP.

Q: Service Adaptation?
A: As a consumer I want to modify it to my needs with supplier not making any change.

14:30 HP

Suggestion - review Corba "Collaborating Component Model" and judge how/if we fit in with it.
Q: Suggesting we pick up Corba transactions, security?
A: Nope.

Component model - trend in the room is towards not defining one.

Suggestion: WSXL runtime might be a extension of a Common XML Runtime (something that incorporated underlying facilities of DOM access, XPath, etc).

Suggestion: XACML + XMLSignature + XMLEncryption all worth reading.

15:15 Kinzan

Q: Can we do bindings within JSP fragment of data to widget?
A: No, has to be at component / service level.

Q: When rendering is there a notion of begin, render, end calls?
A: No.

Q: Incoporating 3rd party security tools?
A: Just looking into that.

Q: How do inter-component messages get carried?
A: Done externally in the State Manager service (not JMS or suchlike)

Q: Different components into one visual interface. Actions need their own private sessions to their remote services. How's the state maintained, how's security handled?
A: Done independently by each service proxy.

Q: What's meant by tradeoff vs performance?
A: strike it!

Decision on content on web site - Put the presentations up there on the OASIS WSCM site in PDF format.

16:00 Bowstreet

No presentation as such, just underlined key points already raised in other presentations.

16:15 Cyclone presentation

Need to consider complex collaborations like the status of transactions/requests in progress. Web flow and processes can be recursive.

Q: Talking about rolling procurement standards into WSCM?
A: Nope, just using supply chain as a complex example with transactions, cancellations, etc.

Kneiling: - Raise side requirement - using industry standards for these things requires a way to bind them to our component model.

Q: Seems to be a raft of issues surrounding flow and assembly/composition. Drive these requirements out to others and focus us on UI?
A: Yes, that should be the focus, but should probably address assembly/composition issues.

Not sure if XForms supports post of a form.

Service APIs for comms and security, eg progress indicators - if that info could be passed up then better feedback to the user could be provided. Maybe provide callbacks to get that information. Consider how to get that information (user feedback) and its influence on WSCM.

Ravi: WSEL may be relevant if it gives us another way to describe remote web service capability.

4:45 Rex Brooks Human Markup Language TC

HML goes to personalization (a) user preferences, (b) tracking behaviour

Q: In presentation space of mapping cognitive abilities of human?
A: Both, personalizations can be recorded in a standard way and the interfaces they expect can be provided.

Q: Possibly runtime container can send user-relevant output (eg, voice) instead of device specific (handheld).
A: Yes.

Q: Any relationship between HML and CCP and UAProf - personalization in W3C and device capabilities?
A: Not aware of tie in, needs to be investigated.

Q: Looked at DAML?
A: Yes, want to suggest adopting the DAML ontology library.

Q: Clarify "it allows users to customize interfaces"?
A: Application providers will do that based on user's profile.

Q: Where profiles stored?
A: Looking for requirements. Single place would be good, but single signon is not standardized yet so cannot expect to be able to do that.

Q: What about privacy? (a) store how/when info was collected, rules on where it can be released (b) record how info can be released.
A: If you give the individual control they become responsible for that. Have been in consulations with Owen Amber(?) to try to address that issue and give users control.

Q: (a) define universe of preference items and give to services or (b) each service defines its own preferences? If the latter, how can it work?
A: Services can add whatever things it needs to the minimum universal base that's defined.

Q: Maybe Profiling runs vertically, not just the WSCM data and presentation boxes? Eg, preferences on security and Quality of Service?
A: Yes, and maybe we need to supply means to not divulge personal info to certain services.

Q: What's the relevance, where does it fit with WSCM?
A: Whole wealth of areas, not just one. RPWS has attributes it wants to specify and use, this is a superset of that.

Q: Privacy, isn't device info more important?
A: It's voluntary, individual does not need to divulge info.
Q: Typically users are punished for not divulging info! Eg Authorize cookies vs not.

17:15 Jacques Durand, Fujitsu

17:30 adjourn.

Minutes, January 8th

Duration

9.00am - 5:00pm

Chair

Charles Wiecha

Agenda for 8th Jan

Day's activities:

9:00 Raman on other standards

HTTP, TCP-IP now stable, need to keep an eye on SOAP, XMLProtocol which are still evolving. Need machine-readable descriptions, hence schema work and RDF. Don't reinvent, but leverage.

In WSCM expect to use XLink, XPath and XPointer heavily. There's been an explosion in XML vocabularies.

UI makes the app. XForms has a rich UI vocabulary. XUL and Glade are XML vocabularies for describing the whole UI and actions and events. The more that is declarative the more can be autogenerated hence dynamic and more flexible. XForms defines very simple and high level descriptions.

Presentation vocabulary: XHTML - handhelds, XHTML+Voice for voice. If device is XML-ready, XML transforms beome very important in manipulating the XML between layers and between presentations.

Think of the browser/WAP as a fat widget whose API is the XML markup.

Events: Can be raised by human or by other system components. System should react to either in a consistent way. DOM2 events provide vendor-neutral API. DOM has an event listener interface giving a way to attach listeners to portions of the tree. XMLEvents allows you to create listeners/handlers using XML (across a network).

• WSDL, UDDI, WSFL growing.

XMLApps: moving from HTML browsers to XML browsers. Events are mediated by DOM. Turns XML browsers into application platforms.

Q: Talking about markup conventions, eg not using Body tags, etc.
A: The XML device would handle this.

WSCM goal is for end-user interaction. Facilitate creation of UI web services that can be consumed and recursively aggregated.

XForms came from wanting to fix broken HTML forms. The XForms model and binding and UI do not need to be in same doc. So the model can be deployed as a web service, so can the UI piece. The binding can be added by the container to pull these pieces together. The wiring would be XMLEvent based.

Q: Mention of legacy apps - clarify?
A: From framework it's from customer point of view, so how to take all of customer's stuff (eg set of JSPs) and bring it into this framework. We'll ask them to spit out XML instead of XHTML, etc.

Q: Will XForms support binary data?
A: Yes.

Q: EDI?
A: Put web service wrapper around things. Implicitly say XML flows over the wire and anything else should be wrapped.

Q: Is there a synchronous implication in WSCM?
A: Implicit in architecture is a chain of n links (with i talking only to i+1 ).

Q: What's relation between Human ML and HRXML.
A: Human ML will take into account HRXML stuff.

10:00 Charlie showed updated WSCM stack showing stateful services etc. Discussed the need to understand (and define) explicit relationships to other groups (XForms, XLink, etc). Discussed what focus of TC should really be. Agreed focus of the TC is end user interaction with strong relationships to underlying layers and infrastructure.

10:45 Led into a discussion on the name of the TC. Vote taken to call the TC "Web Services for Interactive Applications" (which does not necessarily imply the acronym WSIA for any standards proposed).

11:10 Lead in to breakouts.

Discussion started around whether coarse-grained vs fine-grained is an appropriate split. Coarse-grained thought to be the Base services and how to aggregate them. Not at level of MVC interactions. Has a services flavour, a composition flavour. Need to consider the likely technologies and deliverables of such a subcommittee (if appropriate).

Q: Fine grained tied to what transport? Do we see a difference in binding for coarse vs fine? Represented in XML but bound to what protocol?
A: One may be binary, HTTP might suit the coarse-grained.

Q: Events also occur in coarse-grained world.
A: Yes.

Q: Should specify use cases per subgroup first?
A: Yes.

Q: WSFL, WSDL not firm, and they've got competition?
A: We're agnostic and open - should maybe replace WSFL with "orchestration" on the slide since we're not committed to WSFL.

11:45 Given progress voted to stay for the 3rd day.

12:30 Modified agenda - given quality of discussion around coarse vs fine and their implications, voted to continue with the discussion of requirements and push back the breakouts until later (with better understanding of what the breakouts would be).

Q: Examine how runtime's may plug in (eg, into common runtime) - Should maybe investigate Use Cases (but don't lose sight of technical envt we're going to leverage)

Q: Requirements should be stated in order to measure success of committee later. Probably treat the common runtime as constraint, categorize constraints separately..

Requirements suggestions:

1. Support ability to aggregate multiple experiences into one (support application composers)
2. Support ability to define multipage applications including details of how to control flow between those pages.
3. Need mechanisms for both micro and macro interactions
4. Device independence
5. Need to support application
6. Support application producer
7. Support application consumer
8. Support application aggregator
9. Support assembly
10. Support creation of "composite" application
11. Support adaptation of flow- subset and superset. Modify flow depending on results of previous pages (whether interactive or service call). And conversely also allow producer to lock down the flow.
12. Support adaptation of presentation.
13. Allow producer to lay constraints on his output (probably needs to be propagated up the consume chain). Eg, cannot be modified. Most likely do this with additional description doc, beyond the actual service output.
14. Support specializations of producer / consumer that are validators of output.
15. Support loose coupling so supplier can change without requiring consumers to change.
16. Support provider exposing model and data separately.
17. Support micro flow to allow UI components to influence each other. Support both data coupling and presentation coupling of independently developed components.

(Producer & consumer roles can be chained).

Constraints:

Need ability to define multi-page applications including details of how to control flow between those pages.

Q: the last piece in the chain (the presentation) might not be something that can be "consumed" (eg flash)?
A: depends - for design probably don't want to architect that, we may just find in specific instances that the result is not changeable.

Q: more appropriate to view producer/consumer as just a hierarchy (every consumer is potentially a producer).

Q: Do we need to specify formal way to get the options/adaptations that the producer supports, or do we leave it as just another operation that can be queried by a consumer? Seems we may be concluding that since we're geared towards user facing services that there may be a common vocabulary/option set that can be defined (that the producers can use to describe itself and the consumer can expect and react to). Probably define how to extend/use WSDL to get those options in a standard way, but not define vocabulary!

Q: Need to distinguish between adapting flow vs adapting output. Eg, bank wishes to incorporate trav check service but adds value of customer account debit. Implies adaptation point around payment - adapting flow. Also facilitate skipping of pieces of the flow depending on replies received or even results of other service calls.

Q: flow change - adaptation or extension?.. consider effort required in consuming service. Support loose coupling so no need for consumer to change if provider makes some "non structural" change.

Q: Shared context - need to facilitate context/data sharing so services can leverage results of other services. But need to also then consider privileges/protection associated with certain fields.

Q: Probably need to produce a model on the presentation side to facilitate the communication across visual components. Maybe create a presentation model at the container level and allow "containees" to attach to/view pieces of the model they are interested in. Expect this model to be an aggregate of the models exposed by the web services being consumed.

Q: Need to explore relationship between the container and the components within it. What can they rely on, what services are they offered, etc. Is there an existing definition we can use, or is this a new one we'll define? Services available maybe components finding each other, locating presentation widgets.

Q: Container on presentation side (eg XML-capable browser) is probably different from the WSCM runtime container we're talking about. Need to focus on the contract.

Q: Probably have to investigate negotiation between the runtime container and the service provider. Might not be realistic for the service provider to not know about end devices. Data model components might not care. But for best user experience typically services do need to about the devices. So answer is need to support both mechanisms.

Events
Q: only user generated?
A: Nope, possibly raised by application, or system, or even divide by zero.

Q: Need higher level description describing sequence of events? So events feeds into flow discussion. Eg error alters flow.

Q: Support async events (eg stock price change?)
A: Yes - suggestion that once event mechanism is defined it's implicitly supportive of async. Need to consider blocking vs non-blocking calls, + also performance implications of synchronous (blocking) calls. Worth investigating "Tspaces" for discussion of topic.

Q: Should we support events that service provider can drive (implicitly async to the consumer)? - Yup, but only if we subscribed to that. So we're not then tied to request-response paradigm.

Q: Scenario - observer pattern, whereby stock graph receives event notification of change, fires a different event that other (UI) listeners/observers respond to.

Q: Good idea to classify the events - document, user, or run-time generated. Defining run-time generated exception events within WSCM sounds ambitious.

Options for breakout:

Adaptation
Producer
Consumer (aggregation)
Flow
Events
Containers
Models, presentation models MVC
Devices
Context
Preferences
Use cases (Concrete examples, including different delivery channels, syndication, branding, etc.
(Sasha!))

Flow adaptation
Flow composition
Fine-grained composition

Chose following for breakout:

Adaptation (affects producer and consumer)
Producer
Consumer (includes aggregation)

4:45 Future TC Logistics

Frequency of face-face: Aim for next one in 3 months, revisit frequency then. General feeling for 2.5 days rather than 3 (makes it easier for travel). Aiming for 3rd week in (Wed, Thu, half of Fri) April in California.

Frequency of telecon: Agreed 1 hr every 2 weeks.

5:00 adjourn

Minutes, January 9th

Duration

9.00am - 1:00pm

Chair

Charles Wiecha

Agenda for 9th Jan

Day's activities:

9:15 Thomas Schaeck presented WSRP

Need code on portal side to display information in "correct" way, implies code on portal side, which if the remote visual components are described in a standard way can mean a generic proxy and generic UI.

Q: WSRP components always have a visual component?
A: Yes, aim is very specific in providing views that can be aggregated in a portal.

Q: Programming required, eg to wrap all those services out on xmethods?
A: The proxy is on the server side (but implicitly data-only components would need to be wrapped or added to somehow).

Q: Doing this will imply enforcing consistency of presentation styles?
A: Yes. Steps are (1) define concrete WSDL, (2) guidelines for markup, (3) common stylesheets. Step 3 has not been looked at yet.

Q: Voice is supported (not just visual markup)?
A: Yes, the assumption is only that some kind of markup is generated.

Note also that context info is carried in addition to markup, relevations portions like preferences and privacy settings are conveyed to the remote service. Also expecting the portal to intercept/react to events and transmit them to the remote service.

Q: XForms?
A: XForms might be one of the markups generated.

Q: Stylesheets?
A: Assumption is borders, tiling etc are done by the portal, obviously useful to define styles in stylesheets that the remote service can take advantage of. Title, description etc might get stored in UDDI and the portal might take that information and use it in the portlet, but allow an administrator to override it.

Q: Container would handle clicks & forward them. So container is an event dispatcher?
A: Remote markup uses prefixes on URLs which the portal container rewrites. Subsequently it gets the action and invokes the (lookup) remote service via the appropriate instance of the generic proxy.

Q: State?
A: Instance data is carried in messages.

Q: createSession?
A: Makes it possible to maintain sessions between the user and the remote service. JSR 162 (portlet API) has been submitted to the JCP and it's intended that the RPWS is conformant to that and to WSCM.

Q: What if the browser dies - how to cleanup?
A: Typically use a timeout mechanism on the session on the remote side.

Q: Any reason why getMarkup, performAction are separate calls? Implies all remote services must be stateful?
A: Allows more flexible implementation and helps the container. No, state is still optional. The stateless service would not support a performAction operation, just getMarkup.

Q: View switching?
A: Handled by ids on the links indicating that a switch is required.

Q: WSXL talked about lifecycle in the Base component - why is it in here too?
A: RPWS is a specialization / extension of WSXL, there are things in the remote portal web service life cycle that are probably not appropriate to a generic remote component, eg user preferences. Not all remote services necessarily need the context desired by remote portlet services.

Q: Need separate TC for RPWS?

• This generated much discussion. There was general recognition that there is a big overlap/synergy between WSCM and RPWS. The main concern seems to be how to handle that synergy, whether through making it a subcommittee of WSCM, or a separate committee with liasion to WSCM. There need to be very clear charter dependencies stated. Bill C underlined the concern that generally coordination across committees or subcommittes is a hard thing to do. Angel underlined the advantage of having something specific and concrete that can feed into the larger design. (mathML and XML 1.0).
• RPWS is focused very specifically on portlets, without addressing the bigger WSCM issues of flow and adaptation. We should view the RPWS as a simpler beginning point.
• Concern still felt that there is big overlap and need to avoid decisions being taken in isolation in either group that should be worked through the other one for synergy.

Charlie: Have the sense that there are 3 steps in the approach:

1. generic, coarse grained, generic proxy, independent remote services
2. coarse grained interactions, application flows
3. fine grained event synchronization across visual components

10:30 getting ready for breakouts - agreed that by the next face to face we should be able to put a complete (draft) requirements document together, so need to figure out the milestones needed between now and then. eg, gather and document business scenarios.

[ Can we get Sasha's list of use cases in here? ]

Q: Should we by then be able to augment the current requirements to state their dependencies on specific protocols, technologies required, other standards we're contingent on, etc?
A: Yes, this would all probably feed into the roadmap too. Subcommittees will probably be decided upon the lines of technical requirements.

Agreed that the 2 breakouts should be along lines of Producer and Consumer and that both should come back with suggested milestones to get us from here to a draft requirements doc in 3 months.

11:00 subgroup breakouts

Notes from Producer subgroup (actually spent most time discussing Producer needs):

• should be a requirement of the spec not to preclude multiple WSCM containers from operating in the same environment
• need to be flexible in the implementation to allow pieces of the component definition to not be defined until it is deployed or consumed. Eg URL of action not known until deploy time.
• support for binding to additional container services eg billing component, at consume time. Producer needs to be able to specify things that its consumer needs to provide. So actually 2 points of "late binding": 1) how to describe yourself and your needs to your container (eg, runtime URL ), 2) how to describe yourself and your needs to your consumer (eg, need a billing binding).
• implies that all WSIA components (even the smallest "end point" remote services") run in a WSIA container, ie a WSIA container is required to host a WSIA component.
• need to be able to publish at different levels of granularity - data component and/or visual component. This also feeds into flow considerations and validation points. (producer should be as opaque or as visible as desired).
• requirement is to make it easy for adoption so legacy apps need to do the minimum to be WSIA compatible. If WSIA is largely declarative this should ease effort on producer side.
• there are probably 3 types of data - 1) backend acquired via SOAP / web service calls, 2) data passed in from the container (like user preferences), 3) session info to be used in flow. Implies a standard mechanism should be defined for storing data in the container. Might be achieved by binding to locators in different components and using events. So long as this is done declaratively most of the effort should be in the controller and container code (controller asks container to resolve the (late binding) endpoints.

12:00 regroup

Producer milestones:

Consumer milestones:
1. business scenarios, primary one should be portals, define roles and responsibilities for producer
2. definitions, extract from technical requirements as a vocabulary
3. business requirements from use cases
4. technical requirements from business requirements
== should be at this point for April ==
5. base overall architecture diagram
6. illustration of how the diagram ties to the use cases
7. interfaces and languages
8. design patterns, best practices

Raman: Focus in next 3 months should be on developing the requirements doc and focus on requirements for portals, come into the next face-to-face with that as a draft requirements doc.

Suggested that any diagrams circulated should be GIF or PDF so we don't get into software conflicts, agreed that GIF would be best since they can be incorporated into HTML for publishing on OASIS site.

Action: Charlie to merge producer and consumer milestones.

Next meeting

Agreed agenda for first teleconf call:

1. outline of a document
2. template for business requirements
3. bring possible scenarios for elaboration, pick which ones we want on the telecon call

Agreed time of teleconf call: Friday Jan 18th, 12 noon Eastern (and every 2 weeks thereafter).