Attendance
|
|
|
day1 |
day2 |
day3 |
|
William Cox |
BEA |
y |
y |
|
|
Graeme Riddell |
Bowstreet |
y |
y |
y |
|
Greg Giles |
Cisco |
y |
y |
y |
|
Srinivas Vadhri |
Commerce One |
y |
y |
y |
|
Kirk Wilson |
Computer Associates |
|
|
|
|
Sean Fitts |
Crossweave |
y |
y |
|
|
Timothy N. Jones |
Crossweave |
y |
y |
|
|
Peter Quintas |
Divine |
y |
y |
y |
|
Robert Serr |
Divine |
|
|
|
|
Sandra Swearingen |
DoD |
|
|
|
|
Monica Martin |
Drake Certivo |
y |
y |
y |
|
Alan Kropp |
Epicentric |
y |
y |
y |
|
Patel Ashish |
France Telecom |
|
|
|
|
Aditi Karandikar |
France Telecom |
y |
y |
y |
|
Royston Sellman |
HP |
y |
y |
y |
|
Dan Bongard |
Kinzan |
|
|
|
|
Eric van Lyndegraf |
Kinzan |
|
y |
y |
|
Charles Wiecha |
IBM (chair) |
y |
y |
y |
|
Dan Gisolfi |
IBM |
y |
y |
y |
|
Ravi Konuru |
IBM |
y |
y |
y |
|
Rich Thompson |
IBM |
y |
y |
y |
|
Shankar Ramaswamy |
IBM |
y |
y |
|
|
T.V. Raman |
IBM |
|
|
|
|
Rex Brooks |
individual |
y |
y |
y |
|
John Kneiling |
individual |
|
|
|
|
Kevin Brinkley |
Intel |
y |
y |
|
|
Michael Mahan |
Nokia |
|
|
|
|
Terry Cline |
Peregrine Systems |
y |
y |
y |
|
Sasha Aicken |
Plumtree |
y |
y |
|
|
Stefan Beck |
SAP |
y |
y |
y |
|
Jeffrey C. Broberg |
Silverstream |
y |
y |
y |
|
Suresh Damodaran |
Sterling Commerce |
|
|
|
|
Eilon Reshef |
WebCollage |
y |
y |
y |
|
Gil Tayar |
WebCollage |
y |
y |
y |
Day 1 (Wednesday 17th April)
Agenda
9.:00 - 9:15 roll call
9:15 - 10:00 overview WSRP
10:00 - 10:30 review of Embedded
10:30 - 11:00 break
11:00 - 11:30 review of Customized
11:30 - 12:00 general requirements
12:00 - 1:00 lunch
1:00 - 2:00 general requirements (continued)
2:00 - 4:00 Embedded requirements
4:00 - 5:00 >misc ( update on IP disclosures, liaisons with other TCs and WGs, glossary, next rev of presentations and white papers)
9:25 Roll call and review of agenda
Aiming for proposed interfaces by next face to face. Thus aim to come out of this F2F with subcommittees, particularly targeting Enbedded and Customized so weâll be in good shape going into the joint WSIA-WSRP F2F in June.
9:30 WSRP Overview ö Carsten Leue
Carsten led us through a Powerpoint presentation of WSRP. The ppt slide was emailed to the list.
Some general notes:
- itâs obviously portal oriented, content today comes from the portal server, WSRP aiming to extend the portlets to remote portlets. The portal server would still concentrate on user management, personalization and pull content in from the internet. Aiming for plug-and-play so there would be no (extra) programming effort required on the portal side. Also want portlet to be pluggable into different containers (browser, texteditor, Outlook, etc) with no extra programming effort there.
- also defining markup so the container can interpret/handle it. Not restricted to HTML, also anticipating supporting WML, Voice XML, etc, but the first implementation will be to support HTML.
- concerned about security and trust and security of data, considering whether SSL is enough.
- clients (consumers) might be standalone or might be portals that aggregate remote services. Portals with many clients of their own would be expected to cache remote service output for performance.
- content from remote service is markup, not data. The aggregator is intercepting clicks.
- so aiming for simplicity so WSRP services can be created with minimal effort. The only requirement on the remote portlet side is a SOAP servlet and compliance with the WSRP protocol.
- aiming for plug-and-play via UDDI (which is more of requirement on the portal/aggregator).
- user markup preference/locale etc will be passed from the portal to the WSRP service to indicate the markup fragment type desired.
- another key idea is to wrap a portal in a WSRP wrapper so aggregated content can be published as a WSRP service. Both cases (creating WSRP services from scratch and creating them by wrapping existing portals) are equally important. The WSRP wrapper may be the most common at first, with new services taking over later.
- another scenario is where maybe Outlook could be a WSRP container (like WSIA ãsmart buyerä embedding). Itâs a real possiility as a scenario but itâs seen as out-of-scope for WSRP. Also WSIA not looking to get into defining the interfaces between WSIA and external objects and protocols.
Q: If this scenario (the Outlook embedding scenario in the powerpoint presentation) is out-of-scope should the slide be dropped?
A: Thereâs probably value in showing the examples ö showing the possibilities does not imply we need to define the mechanisms.
Q: Shouldnât it be in scope for WSIA?
A: Non-portal consumer is definitely in scope for WSIA. But out-of-scope for WSIA is defining the mappings across protocols. A focus for us in the Embedded case is to make sure we do not get too portal specific.
WSRP aim for instance creation and getting markup as being in the ãcommon areaä across WSRP and WSIA. Arenât WSRP services specialized WSIA services? WSRP should be compliant with WSIA.
action: all (Charlie) - Not sure
that weâve defined clearly enough the relationship between WSRP and WSIA. The
general feeling is that WSRP is a specialization of WSIA. We need a joint
communication/requirements definition.
Q: URL rewriting ö if thereâs embedded code / applet / javascript is it being addressed/considered by WSRP?
A: yes J
Aiming for 1st draft of WSRP in July 2002. Then 8/02 first version of reference implementation, 10/02 first draft, 11/02 reference implementation, 12/02 WSRP spec 1.0.
Q: Security relationship between WSIA and WSRP?
A: The set of base interfaces donât address it. Security in WSRP would be to have a special binding (a protocol step). Probably premature to make a statement here. Maybe subtleties in Lifecycle will make a difference. WSRP havenât talked about forming a security subcommittee. Might be covered by a relationship with WS-Security.
Q: Might also want to consider standard caching mechanism?
A: Have discussed adding indicator to say if something is cacheable or not (and if so for how long). This might be a slippery slope ö some of this might bush down into WSDL too. Want to be careful not to pull everything up into the interfaces.
- also note the handle (for session/instance mapping) is a short trem thing. We may want to be explicit in the spec and state ãthis is how weâre doing the instance mapping, and itâs short term pending exapproved extensions to WSDL, etc.
11:00 Embedded Requirements / Use Case ö Alan
- Need to be clear as we g through that weâre not assuming a portal
- Need to be specific that the producer service is not aware ofÊ customizations. Also there may be a link to the producer configuration page and no customization on the Consumer side. The Consumer here sees every Producer as being the same and does nothing special per producer.
Q: Also want to be concerned about ãper userä configuration?
A: Feeling in WSIA that we should not be considering users, and that this issue should be in the domain of WSRP. WSIA should talk about properties and persistence and the mechanisms between Consumers and Producers, and allow WSRP to extend that.
Q: Are we assuming a remote admin role in WSIAA?
A: Expect there will be admin need on both the Consumer and Producer But thereâs no Customization in the Producer-Consumer conversation.
Q: So we should remove the admin actors in the Embedded case?
A At least state that itâs not in the Embedded Use case (rather than ignore it altoghther). ãThe mechanism by which the properties are set is out-of-bandä.
Q: Are we happy to say that content-type is out-of-band too?
A: Yes ,think we are. If we say we are ok with this we allow Producer to take away or switch off some URL, etc but we do not require it.
Q: What about the HTTP Header stuff like User-Agent?
A: We may need to state that there are (1) a limited set of properties which are(2) optional at the Embedded level (and required in the Customized case) which are (3) dynamically dicoverable.
- Embedded Case could probably do with a state diagram.
12:00 Customized Use Case ö Ravi
Q: Do we need to state what properties weâre not describing?
A: Yes, should probably state whatâs pushed up into Coordinated, Orchestrated. When we get into it we might even fold Coordinated into Customized.
(Itâs what is done by the Consumer that defines the Use Case ö Coordinated moves into fine-grained coordination of Producers, then full screen time-based navigation is Orchestrated).
- thinking that we might want to categorize the properties by an MVC-like break down ö model/data oriented, and presentation oriented.
action: Ravi, Alan ö should probably go into the Use Cases and state that the flows described are descriptive, and not normative.
So far the doc does not describe the kinds of elements ö thinking that maybe we should categorize the product elements.
12:45 break for lunch, look at requirements after·
1:20 Review of General requirements ö Eilon, Gil
(Modifications being made live to the Requirements document)
- Simplicity ö consensus that if coice was between simplicity for the service developer vs simpplicity for the tool developer, weâd favour the service developer.
Q Struggling with where to put Scalability?
A: Should probably have Preface section to describe intent, aims. Scalability and suchlike are qualitative goals, but not really Requirements.
- wherever we have ãreasonablyä in requirements should take the wordsmithing offline.
- acknowledge that weâll revisit Lifecycle and persistence of properties (as customization data) in subcommittee.
- in interests of time we agreed that weâd make sure (idf possible) that we understand the intent of a requirement and take any disputed wordsmithing offline, assigned to folks who had strongest feelings on the matter.
15:55 Review of Requirements for Embedded Case
16:40 Set down outline subcommittee thoughts, got this initial ist..
Lifecycle
State
Persistence
Session
Discovery
Customization
WSDL Description and Protocol
portTypes
interaction diagrams
Self description
Presentation
Std look & feel
>Markup rules
Action routing
URL Rewriting
Navigation
Properties
>Context
Security
Tracking Standards
Day 2 (Thursday 18th April)
Agenda
9.:00 - 10:00 WSRP teleconf
10:00 - 12:00 Customized case requirements
1:00 - 5:00 Proposed interfaces for Embedded case
1. WSXL Base component
2. IWS WebCollage
3. Epicentric
4. Proposed interfaces for WSRP
9:00 - 10:00 WSRP teleconference
Sasha (as WSRP Secretary) taking minutes.
10:15 Review of Customized Requirements
Aiming to get a sense of what we need to do in subgrgoups for the Customized case, and understand what kinds of modification we want to support. Hoping to find a common framework that allows customization on either Consumer or Producer side as desired.
- note that some data might be inserted by the Consumer (private data) and also Producer needs to be able say what elements/properties are modifiable/not modifiable.
- make sure R203/204/205 reflect that it should address Producer/Consumer rights, not just scalability.
Q: Should we be trying to enforce no change through digital rights management?
A: Consensus is that it would be out-of-band. Weâll look to put in mechanism for Producer to indicate his desire that certain elements should not be modified.
Q: Need (SAML?) Policy Document in the datastream?
A: Possibly, or might be a portType on which it can be requested. So we should state in the spec that if such a policy stmt is in place, the Consumer SHOULD adhere to it.
Q: Should we say the policy statement is out-of-spec?
A: Need to look at it in subcommittee and see if that makes sense. Right now leaning towards declaring it as in-spec. Could maybe leave a slot in the protocol for 2.0 (by which time other security standards might be firmer).
- need discussion on timelines ö Customized is probably a few months out from Embedded.
- transformations//customizations might be pre-porduction or post-production. Some transformations cannot be done pre-production,
- many customizations are custom, hard to specify them declaratively. It seems dangerous to require that Producer should declare all possible customizations. Need flexibility to state either those that are allowed or those that are not allowed. Also need to be careful to avoid Consumers having too much awareness of the properties of the Producer, since that may lead to tightly coupled systems (Producer changes implies Consumer needs to change too ö not usually desirable.
- pre-production customization allows the Consumer to influence the markup without needing to get it himself. Also consider this as modifications on the model, which subsequently influences the output. Conversely Adaptation Data Language addresses modification to the markup which is post-production customization.
- concern that if we go in the model modification direction we need to delve into a model description language too, concern about the complexity of that language.
- ADL must accommodate ommitting a data item from the view but keeping it in the model, so it can be relayed back to the remote service.
11:35 FastMem Demo - Shankar
Illustrates ADL working to indicate customer part numbers in the output stream, and also calling methods on remote service to add columns with specific data and regenerate output. FastMem sends out data, extra columns are achieved by preproduction customization (method calls). When the FastMem HTML is embedded in Acme, the logos are shrunk down, some image links are removed and the background colour is changed. Acme adds columns for in//out of stock and price. Also intercepts ãmore infoä and display custom information, not the FastMem ãmore infoä.
Q: Why not just use a data service and build the table yourself? Concern that this might not be the best example of a WSIA service.
A: Could do that ö this is serving to illustrate some ADL and customization points. Real world example might be that the FastMem service has stipulation that when their data goes out it always has their logo next to it (branded).Ê But note that if WSIA was not used here weâd have a (moere) complex app at the Consumer side, and furthermore all Consumers would need to come up with that complexity. So 1. Weâre just customizing an existing useful piece of cutionality with hooks, 2) FastMem could add pieces to the process without Acme needing to make any change (or be aware of it) 3) Kingston retains process and workflow 4) doesnât take much imaginination to come up with a complex app that it would be bad for many Consumers to have to recreate.
12:15 ADL Presentation ö Ravi
(Powerpoint mailed to list).
- validation. Maybe we could supply a validation service rather than stipulating valid types are Integer. In fact the validation service would need to be on the Producer, it could be some other SOAP service on the Net.
Q: Should we have a Data Dictionary to specify valid values?
A: Bring this up again later in subcommittee ö there are other organizations looking at this stuff.
- ADL work-in-progress: Looking to unify the models and mechanisms for Consumer and Producer customizations. Not sure if possible or not.
12:50 lunch
13:50 Customization discussion
Want to examine the roles of Customization. If we differentiate between MVC types of customizations on the Producer side, are there standards in place that we migh be able to leverage? Need to investigate idea of separate ãpacketsä for the data and presentation customizations.
- can expose properties affecting the schema of the data model in the Producer (eg restrict calendar to March). Some concern whether this was really realistic (or a good idea).. It necessarily requires tight coupling in that the Consumer needs awareness of the Producerâs schema (to know what restrictions are valid). Accepted that you could only realistically ãreduceä the scope of the Schema, not extend it, but still scepticism on this one.
- expose data instance values. This is what weâve typically seen as pre-production customizations, where modified data values influence the output generated.
- presentation level ö pass in additional markup fragments to be inserted into the output by the producer (eg adding form elements).
Orthogonal to the actual setting of the property values is the timing of the calls, semantics of a valid call sequence. This will be important for the Coordinated Case.
Q: Can we preset values?
A: This leads to Lifecycle and persistence ideas which might accommodate preinitialize/preset of values.
- acknowledged that thereâs a lifecycle involved within a single request too, and weâll need to get into that level of detail in time.
- acknowledged that we have levels of customization ö fine-grained/coarse-grained. The navigation in the FastMem example was primitive, but was still a different level of customization that the page presentation
- explored idea of VBX analogy and callback from Producer to Consumer to get data. Recognise that the Producer needs to give the ability to (a) call onto himslef or (b) call the consumer. So can the Producer ever make arbitrary decisions on presentation? In some cases the Consumer might not want to call the Producer at all. This is a good scenario. But even then if we separate the view and the data we could add empty columns onto the Producer and add in the data later. We might be concerned/hope to only create the presentation stream in one place.
14:25 debate subcommittee needs
Maybe 3 levels of Customization
a) transport (related directly to HTTP Headers)
b) Opague level (maybe the Producer offers an edit interface that the Consumer passes on to his user)
c) Properties that the consumer does not know about (producer-specific)
Whether there
are 3 levels needs to be drilled down on in subcommittee, but weâll take a stab
now at naming the 3 categories Platform, Opaque and Producer.
- regarding thought of action routing being delegated to WSRP ö WSRP is not really interested in multitier scenarios, and only interested in routing, not interpretation. So should make it a joint subcommittee or at least monitor what theyâre doing in this area.
- Security ö
Cannot delegate it or layer it on afterwards. Need to state how weâre going to
apply the standards. Consider encryption of payloads, MAC, SSL, other standards
groups, etc. ö so it must be a subcomittee, cannot ignore it.
- Quality of Service ö WSArchitecture has a RSA group to look at this. Should maybe monitor that.
- identified subcommittees as:
Joint WSRP/WSIA
interfaces:
WSIA specific WSDL
description & protocol for both embedded and customized:
Ravi
(Chair), Dan, Shankar, Rich, Gil, Alan, Terry, Monica, Graeme, Sean
Customization:
Eilon
(Chair), Charlie, Shankar, Stefan, Terry, Ravi, Tim, Pete, Royston
Security (joint
with WSRP):
Rich
(Chair), Pete, Monica, Royston, Graeme, Srinivas
Suggest that they be true OASIS subcommittees with public correspondence, charter, minuted, etc. Let them settheir own agendas and schedules (but weâll broad-brush that here too..).
15:20 break
15:45 general milestones conversation
Suggested
milestones for subcommittees:
Joint
WSRP/WSIA interfaces subcommittee:
|
June Joint
F2F |
review draft
of spec ö combined with WSIA specific |
|
July release
w/WSRP |
1st
draft of spec with WSRP |
|
3Q 2002 |
sample
implementation |
|
4Q 2002 |
final
iteration on 1.0 spec |
|
1Q 2003 |
|
Customization
subcommittee:
|
June Joint
F2F |
review draft
of Tech Requirements Doc, sketch of a spec/architecture model |
|
July release
w/WSRP |
1st
draft of tech requirements |
|
3Q 2002 |
1st
draft of above spec |
|
4Q 2002 |
sample
implementation |
|
1Q 2003 |
final draft
of 1.0 spec |
WSIA specific
WSDL descriptions and protocol
|
June Joint
F2F |
review draft
of spec |
|
July release
w/WSRP |
1st
draft of spec w/WSRP |
|
3Q 2002 |
sample
implementation |
|
4Q 2002 |
final
iteration on 1.0 spec |
Security
subcommittee:
Joint with
WSRP look at other activities and figure out (a) what we need and (b) what
other initiatives might be appropriate to help us and (c) what we need to do in
addition to that.
|
June Joint
F2F |
|
|
July release
w/WSRP |
define
relationship between WSIA and other bodies |
|
3Q 2002 |
review 1st
draft spec for security exposures |
actions: Other
milestones (short term):
action: Tech
White PaperÊ - Charlie, Terry, Gil, Ravi
action:
Business/Executive White PaperÊ -
Charlie, Terry, Shrinivas
action:
Presentation ö Charlie (Terry editor)
action:
Definition of relationship with WSRP ö Alan, Ravi
action:
Glossary ö Jeff, Eilon, Dan (need draft for F2F)
Demo ö defer.
Will probably want to illustrate Consumer against several Producers, authored
separately, running on different platforms, using different technology.
action: Define
demo by next F2F ö Shankar, Pete.
16:30 IP
Nowâs the time
(now we have an idea of what weâre getting into!) to declare IP and submit to
OASIS a declaration of any patents awarded or pending that apply, before
related detail gets into any spces.
action:
Charlie ö email to the list the OASIS URL with the IP policy statement
action:
Charlie (IBM) ö will disclose 3 patents that might have an impact.
Seems that a
company doesnât need to declare what the patent (if applied for) covers, but do
need to declare whether the technology will be made available on a Reasonable
and Non Discriminatory Basis or Royalty Free etc, which might possibly cause
other contributing companies to reconsider whether they want to be part of the
exercise or not. Itâs also maybe possible that maybe if the patent is not
declared it will not be enforceable after the fact. So·
action: all ö
Need to get with their own companyâs legal departments and determine if they
might have any patents that might need to be declared, and if so determine what
patent statements need to be made with respect to this committee.Ê Aim to get that info into the committee by
the next Face-to-Face in June.
Day 3 (Friday 19th April)
Agenda
9:00 roll call
9:05 Review of possible / proposed interfaces for Embedded
a) IBM - WSXL Base component
b) WebCollage - IWS
c) Epicentric
12:00 adjourn
9:05 Review WSXL Base Component ö Rich Thompson
(powerpoint emailed to list)
- emphasis of presentation on the WSDL portTypes
- key tracking
point is the definition of WSDL extensions for stateful services.
WS-Description is focused on 1.1 and might not get to this until 2.0.
- ebXML Tr&P took a lot of flak for investigating protocol and then just adopting SOAP w/attachments. We should probably be very explicit in our spec that our session Handle on the portType is just a placeholder in advance of whatever mechanism WSDL later defines.
action: Charlie - to track this via Web Services liaison responsibility. Also need to determinepossible timeframe for stateful service definition. (Also Greg has associates on the WS-Description committee.)
action: spec authors - probably need a section in our specs to state dependencies and workarounds and likelihood of change.
- So proposal is of ãhandleä ö thisâll change with WSDL extensions, and it might later disappear down into the infrastructure much like HTTP sessions are in that sense invisible too. Hanlde is an opaque reference to hold on to and pass back on subsequent calls.
- separating portTypes into groups helps with clarity. The WSDL spec today says ports do not communicate with each other. We probably need to clarify this with the WSDL spec folks as it does not seem correct to make that restriction. Maybe the next rev of WSDL wil be loosened.
Q: getServiceDocument should return a document?
A: a debated point ö if a URL is returned then the URL (result) can be cached. On the other hand returning a URL relies on the Consumer being able to get at that URL, which might not be a good assumption.
Q: Stateless sservice & createInstance?
A: Might return null for the handle . Think thereâs a need for the Consumer to determine if the Producer is stateful or steateless. The handle would then have a null value for subsequent calls. If there was an erro in the createInstance a SOAPFault would be returned rather than null.
Q: how to get all properties?
A: getProperties(handle, ã/ä) would return all since WSXL expecting that the property names are all referenceable by XPath expressions.
- some debate around whether XPath was good idea or not (makes it harder on tool developers), but acknowledged that the Producer properties are very likely to have depth (eg applicant/name and coapplicant/name . But do want to have mechanism for getting all properties without needing to supply getProperties( handle, <root el>) since we donât necessarily know the root element name. Want to keep it simple for tools. Plea to keep it flat and not go down the RDF path. Maybe can allow for supplying name or XPath.
Q: Is there an annotation mechanism?
A: Yes, covered by the getPropertySchema.
- returning the changed property values is seen as critical for the higher order Use Cases such as Coordinated. The set of changed values needs to be returned since changing one value might have a knock-on effect onto other values, which in the coordinated case might then imply invocations against other Producers.
Q: Should the property schema be part of the WSDL?
A: Some debate about this too, but generally felt that the property schema has nothing to do with the schema in the <types> section required to define the complex types in the operations. So answer is probably no.
Q: Could getPropertySchema() change between invocations?
A: Probably not.
Q: for getOutput( handle, list) ö is the list persistent across calls?
A: Yes. The returned Elelment contains potentially 3 things ö a handle (if null came across before and now thereâs an instance), properties, and output markup.
Q: Should review portTypes with WSRP?
A: In WSRP Interfaces and Protocols thereâs a discussion that only opaque is allowed (with no signatures and using setters beforehand). From WSIA point of view that might not be good enough, more control is needed. So we should probably give this presentationÊ to that WSRP subcommittee.
Q: Shouldnât invokeAction return an Element?
A: Seems like there are a few cases wher e that might make sense.
- concern/hope raised to follow the message/bean concept ö instantiate, set, set, set, msg.Send. It might be a more familiar paradigm to developers. Also concern that invokeAction and getOutput as separate methods might be an unfamiliar paradigm to todayâs J2EE developers who are used to invokeAction returning output.
10:10 WebCollage IWS ö Gil Tayar
(presentation emailed to list)
- note URL leakage ö sometimes we might wish that not all URLs are rewritten (eg in case of mailto).
- possible mechanism for URL rewriting is that Consumer supplies base (controller servlet URL) to Producer, Producer uses that base in the URL generation. In Consumer when the link is clicked on it goes to that action in the Controller servlet.
- note occasional need (useful) to allow the Producer to return a markup fragment, not necessarily a whole HTML document.
Q: Entry and Exit points are lifecycle of a subtask?
A: Not really ö they mark the lifetime of a Producer instance.
- note that multiple portTypes / EntryPoints mean that the property list for individual units of functionality is reduced. One ãmega-methodä implies a superset of all properties.
Q: Events is a subscribe model?
A: Not really, itâs really a callback mechanism onto the Consumer.
- property sheet is equivalent to notion of portlet template, an out of band mechanism for setting persistent initial values for the Producer instance.
11:20 >Epicentric MWS ö Alan
- some debate on limitation of Consumer holding all the data and needing to pass all info from Consumer to Producer. Implies Consumer also needs access rights for data that the Producer should be encapsulating. Goes to security model for WSRP/WSIA.
- counterpart to ãperformActionä would be ãviewRequestä. API not in presentation but downloadble from Epicentric.
11:50 adjourn