XML Protocol Abstract Model Subgroup
Teleconference Minutes
Friday, March 9, 2001
Attendees:
Martin Gudgin (MG) DevelopMentor
Marc Hadley (MH) Sun
Oisin Hurley (OH) IONA Technologies
John Ibbotson (JI) IBM
Mark Jones (MJ) AT&T
Yves Lafon (YL) W3C
Jean-Jacques Moreau (JM) Canon
Henrik Nielsen (HN) Microsoft
Nick Smilonich (NS) Unisys
Lynne Thomson (LT)Unisys
Stuart Williams (SW) HP
Mark Baker (MB) Sun
Scott Isaacson (SI) Novell
Krishna Sankar (KS) Cisco
1. Roll call, scribes for minutes/action items (5 mins)
2. Agenda review, call for AOB (5 mins)
3. WG Chairs Items (10 min)
4. Schedule/Goals (10 min)
· Propose to have Working Draft Abstract Model document by end of March
· Wrap up v1.0 and leave stable for a while!
· Publish consensus document, leave out (cleanly) areas of non-agreement.
· Need volunteers for assignments 3-7 opportunities in Work Item List below.
· Organise weekly phone conferences through end of March to track progress.
5. Review of AMG Work Items List below (30 min)
6. AM Issues list from AM document (5 min) [See status below].
7. Glossary Reconciliation (20 min)
Remaining terms:
XMLP Module, XMLP Block, XMLP Handler, XMLP Processor, XMLP Application, XMLP Layer, XMLP Operation.
8. Any Other Business (5 mins)
14th March 2001 at 4pm GMT, 5pm CET, 11am EST, 8am PST.
· AMG Work Item List - Agenda Item #5 (Volunteers : Various)
|
AMG Work Item |
Status and Volunteers |
|
1. Reconcile Glossary and AMG terms into a single Service Model |
Nearing completion. Stuart, Henrik and Martin. Marc Hadley to work on XML Processor term. Handler, Module, Block wording - Stuart |
|
2. One-way only model? One-way plus two-way request/response? |
Stuart, Henrik to lead. Henrik to draft a contribution to close loop. |
|
3. XML Protocol Modules · Message Processing Model (cf Mark Jones posting [1]). · Message Path and Handler Targeting · Fault handling at Handlers/Intermediaries |
Review Mark Jones paper during next AMG Call (3/14). Marc Hadley and Mark Jones to lead. |
|
4. Items 4/5 deleted and now owned outside AMG by action of WG telcon 3/7/01 |
None. |
|
5. Items 4/5 deleted and now owned outside AMG by action of WG telcon 3/7/01 |
None. |
|
6. Model for Arbitrary Attachments (ref. ebXML convergence subgroup).
Mapping between SOAP plus Attachments and the Abstract Model. |
Generally agreed this is a binding issue. Current AM document indicates as such and coverage is acceptable.
Stuart to work on mapping.
|
|
7. Mapping between SOAP 1.1 and the Abstract Model. |
Review with David Fallside how to present - Stuart Proposals : Annex (appendix) or in-line with Abstract document text. |
|
8. Mapping between Requirements Document Requirements and Abstract Model |
Scott Isaacson (volunteered in absentia Stuart will follow-up). |
|
9. Mapping between Requirements Document Scenarios and Abstract Model. |
John Ibbotson to look at Scenario Mapping (per Stuart request). Martin Gudgin to help. |
· Review with David Fallside the preferred presentation of the SOAP 1.1 vs Abstract Model mapping (Stuart – Work Item #7)
|
Abstract Model Issue |
Status |
|
1. Requirements and AM Glossary |
Work in nearly complete. |
|
2. Henriks whole Section #3 issue with API vs Abstract Wire Protocol Model and specific message exchange patterns. |
TBD. |
|
3. Fault handling |
Discussed and encapsulated in Work Item #3 above. |
|
4. Concept of Unicode normalization may want to allow intermediaries to modify message content. |
A note. Content fits in with Module Processing model. |
|
5. Subgroup thinks in Abstract Model should be mapped against various scenarios in Requirements document. |
Work in progress. |
|
6. Fig 2.1 suggests a one-one correspondence between handlers and blocks. Are handlers allowed to process multiple blocks? Is a given block allowed to be processed by multiple handlers? |
Answer is yes to both. |
|
7. Concern that the generation of UnitData.confirm (now UnitData.status) might need further explanation. |
?? |
|
8. The use of intermediaries in a response path is not illustrated. |
This hinges on Request-Response as a primitive operation – Work Item #2. |
|
9. A direct single hop interaction is not shown. This may give the impression that all operations pass through intermediaries, which is not the case. |
?? |
|
10. Figure 2.1: would like the handlers to be given some concrete purposes: eg. Signature generator, Signature checker, Path handler... |
?? |
|
11. The relation between the terms XMLP Module, XMLP Block and XMLP Handler may need more work. |
Work in progress – Work Item #3. |
SW: <opening agenda review>
10 minute item for David Fallside – he indicated in WG call Wednesday he would join call to talk about AMG work.
Had focus before f2f to get document ready for f2f meeting – where we go from here and by what time – bunch of f2f AMG work items – close this week and plan forward on work items list
Need to listed issues on front of abstract model document.
Agenda Item #7 - Glossary. This week SW, HN, MG got together and thrashed out WG and AMG glossary definitions. Not complete – use call time to finish off glossary.
HN : Put glossary item first since WG called for as priority.
Schedules and Goals – Agenda Item #4
SW: Item #4 is schedule and goals
Still some AM document issues going in to F2F – get to a mature state by end March – “pretty big challenge” – also what DF wants from AMG team – put out a working draft with sufficient consensus – might mean there are bits of doc that can’t be published – work items will require volunteers.
Weekly teleconferences – need these to get to this milestone.
MJ: Does this mean minimal useful abstract model document in terms of coverage of XMLP?
SW: Done in early days – pretty good coverage with sections in last draft – MJ’s work fits in well in section on modules and processing (number?)
MJ : I added because there was a hole in model. Are there other holes in AM that need to be flushed out in March? Could we vet a spec. against it?
HI: What is minimalistic model that can present an abstraction that people can understand and solve questions they have on the subject and how it fits in world. Correct?
MJ: Does abstraction hold enough information to answer those kind of questions that will come up.
HN: One of goals we should provide is (charter) people should take first working draft and run with it and start writing their XML protocol modules –they need guidance on how to do that – need syntax stuff, processing stuff, whether it needs some binding stuff and how these things fit in - then we have achieved goal.
SW : Henrik, there are two items in WG list, items 4 and 5, I have now taken out because DF said they will go elsewhere for template work on that
HI: When you write a module this is where you are – these are things you interact with – that’s first diagram in abstract model
MJ: My view is abstract model makes layering clear and answers as far as possible the big semantic questions and beyond that - exactly how things are divided up, how technology is expressed, what that syntax is – that is all the specification side.
SW: How are we doing Mark?
MJ: Pretty well on layering in SW diagram – like that very much – glossary definitions and getting those pieces straight – don’t have a good sense of a handler in a module and some glossary items – more comfortable when those semantics get nailed down. The area I contributed to corresponds to the SOAP section with the semantics for mapping of SOAP actors onto blocks and how rich that should be, etc.. – We pretty close.
SW: Is end of March is an aggressive target?
HN: We don’t have a choice
MJ: Agree
JI: Providing we scope what to do by the end of March it is achievable – if we leave it open-ended there is no chance.
SW: The Work item list is intended to do that scooping by end of March – can’t add that list.
SW: <Weekly Teleconference discussion>
Could try for Wednesday ahead of main working group conference – that would help reporting into main working group as well.
All: Agree – Wednesday at 4 GMT 8 am PST. France is 5 PM
Glossary – Agenda Item #7
SW: Do you want to pick up where we are Henrik? – I am not sure - Martin and I have kind of concurred over some definite thoughts.
HN: Your write-up and looks fine –what you call the second viewpoint is fine.
SW: So if we can resolve the wording in the glossary in tune with the second viewpoint then we don’t need to make a big noise about it. Excellent.
HN: Gudge, we pretty much got through it didn’t we? Gudge did you send out updated table?
SW: There is list of terms in Agenda Item #7 we didn’t settle. “Processor” and “Application” are two we didn’t get to – Gudge sent back some edits we agreed in tail of conference and also thinks Gudge missed first one which was “XML Protocol”.
MG: Document SW sent out with MG edits has table with gaps in right hand column for “layer block handler module”, “Application Processor, “Operation”.
SW: Yes - Those are ones called out today’s agenda.
MG: Ok so we fixed “block handler module” I think
SW: Yes just need a little work on that one – “Processor” not discussed –“layer” and “operation” are in the abstract module document and don’t need to be fixed in the requirements document – so we could avoid stress on those.
MJ: The three that you fixed – there is no new document yet with a filled out third column for those?
MG: There is an SW email that is copied to the archive – will dig out URI from archive.
SW: Re “module handler” and “block” there seemed to be two viewpoints in our discussion – couldn’t resolve them – so take that to email – SW wrote email to self and HN/MG saying – HN agreed with SW and MG’s position. MG can dig out archive message.
SW: “Application” – there is no definition in the glossary – left as TBD.. In the Abstract Model, “XML Protocol application” is “client or user of the services in the XML protocol layer…” – one sentence description with little text definition after that.
HN: In the glossary it is intentionally not called “XML Protocol application” – it was just called “application” – it means a piece of program – is it useful (question?) to differentiate between set of modules that are instantiated by some handlers – term “application” will say all these handlers or modules are governed by the same application – is that a term we necessarily need to call out, other than saying whether an XML protocol message is composed by invoking n applications.
SW: For the Abstract model, the term I am looking for is a name, label or entity that uses the XML protocol rather than entity something that provides the XML protocol – I picked “XML Protocol application”, but it could “XML Protocol Layer Client”…..
HN: There is “Handler” so what is the difference with a handler that uses the XML Protocol or a module that uses the XML layer protocol.. and an “application”?
SW: I think “modules” and “handlers” are finer-grained than the notion of application.
HN: Are you saying all that is needed is a term that is a set of things in uppermost part of diagram (above XML protocol layer) – could say a set of modules but instead want one term that doesn’t necessarily imply anything how they are implemented.
SW: Want to encapsulate sense of the user of the layer as opposed to provider of the layer.
MJ: Is that the user of the end-to-end service, or that the user with respect to one node,.. – How are you scoping that user?
SW: I mean the user at a node.
MJ: Do we want a term for the application as it exists across all the various nodes, intermediaries, etc.. like shopping application.. all of the client code across whole path?
SW: That is a different concept – whether we want to name that….
HN: That is what a module does – module spans one to the other.
SW: Does a module send a messages?
HN: No.
SW: What sends a message?
HN: A “sender” (laughter).
MJ: I am confused Henrik – thought a module was something that was the basic operative thing for a block which is an operation which takes place at a particular node.
HN: Yes – specifically – a locking module that could be dealt with on each node when it comes by, by each XML protocol sender and receiver in some capacity and just handed off – how it is actually be handed off may different from other things in the message. My concern is that XML protocol and SOAP have the notion of headers and there is composability model so you can stick things in headers and where they come from – it is ok to have a common term for a set of blocks or a set of handlers acting on a message.
SW: So you think it is a useful term.
HN: Yes but I think application is not right.
SW: Would you like to propose a different name for that concept?
JI: It is a very difficult concept to put a name to. There are now potentially distributed handlers with possibly changes of operations on messages at distributed points – it comes down to who really originated the message and where is it going to – anything in between, you don’t know what is going on inside the protocol layer and or above it.
HN: This is breaking down the notion of what an application is – there has been component software for a long time, this is first time you have had that in a protocol.
JI: Are “source” and “sink” suitable terms? – something is the source of a message and something is the actual sink of the message – kind of two endpoints.
SW: What type of things are they? - and are intermediaries the same class of things.
JI: They are not ultimate sources or sinks of messages.
MG: They are.
HN: Is the sender and receiver concept we have is actually sufficient.
JI: You may well be right – if words can be put around those to show that those are the true endpoints, i.e., the real originator and ultimate recipient of the message.
SW: Can someone take a work item on this?
HN: Here is a proposal – use the terms “XML Protocol sender” and “XML Protocol receiver”, rather than differentiating….
JI: Some of previous versions of the glossary implied sender and receiver were within XML protocol layer – SW is trying to get at something above the XMLP layer.
SW: This is something that uses the XMLP layer – would be happy with “Layer Client”, but people don’t like the client word because it speaks of client/server.
SW: The other term to settle is the “XML protocol processor” term. The glossary definition: <SW read definition>. “
MH: Surprised definition doesn’t mention handlers at all, my understanding was processor invokes the handler for a message.
JI: I would see that AMG definition replacing XML Protocol applications with XML protocol handlers. This is providing services of the layer to the local handlers.
SW: May be 80% with that.
MH: Close enough.
SW: How about original Glossary definition?
MJ: Noticed it talks about generating faults where there is bad data in a block, but there are other types of faults like data ok, but handlers are missing – doesn’t cover all fault cases.
SW: In the AMG definition it forces the rules that govern the exchange of XML protocol messages which would include the rules for generation of faults.
HN: Definitions add to each other - both say the processor crunches the message according to its own rules, and there are things in the message it doesn’t deal with.. all the blocks - it deals with them at the XML protocol layer, but it then might spin those off to handlers.
MH: I would say that is the processor’s job – take the message in and work out which handlers get which parts.
HN: There may not be handlers and there might be wrong things – it has its own processing model. We could just add the definitions – it takes message in, it uses its own rules to process the message, that might generate a fault – what it also does is hand out processing of blocks to the handlers which may also generate faults.
SW: Could I ask MH or HN to draft text offline and send to group?
MH: Happy to do that.
SW: Do you want to try “application” as well?
MH: No.
HN: Should actually talk about handlers for “applications”.
MH: I would want to replace “XML Protocol application” with “XML Protocol handler” in the AMG definition – wouldn’t actually mention application at all.
SW: Let’s see how it turns out.
MH: Process question – CC to Working Group or to Dist-App?
SW: Just trying to converge on a set of definitions, so CC working group just now - hopefully we can close on this quite quickly. We didn’t circulate the full table to the group outside –assuming once we have right-hand column, HN will edit back into his editor’s copy.
MJ: Can I get a quick read. The proposal I created was sent to the wider distribution list to get comments from all quarters – ok?
SW: Fine. This Glossary action was from David Fallside at face-to-face.
MJ: So internal comments just go the AMG working group, but general proposals/comments go to general list.
SW: General discussion on the Abstract Model has gone on the Open List. Notes from these meetings have been made available on the W3C Web site. SW usually sends out a pointer to those notes.
AMG Work Items List – Agenda Item #5
SW: I presented Work Items list in roughly priority order at the Face-to-Face. There was a strong urge from Fallside to up the priority for mapping of the Abstract model SOAP 1.1 and SOAP with Attachments – also the mapping with respect to the Requirements documents and the Design Scenarios.
MG: So DF is asking us to move Work Items 6-9 to the top of the list? Wasn’t sure what DF wanted. Shame he is not here to tell us.
SW: He seems be trying to get some commitments from us.
MH: Got the impression that he didn’t want the work items at the top of the list, but didn’t want them at the bottom of list either – the glossary has to stay top priority.
MJ: Need a bit more convergence before we can do that.
JI: David was treating it as a sanity check – SOAP exists at the moment and there are holes in it – if there is something fundamental that doesn’t match between the AM and SOAP then there is probably something wrong.
MG: Agreed. Stuart, you put this work item list together in the order that you think will get us a document in the shortest amount of time?
SW: Yes. Reconciled glossary has taken first priority because it is tied to the re-publication of the Requirements document. The Service model has the fairly significant comment by Henrik against Section 3, and the discussion of one-way or two-way, or request-response as being primitives - discussion is not resolved and not sure how to resolve.
MH: That is such a fundamental issue, we really need to resolve that (primitives).
HN: Agree. The trick is whether we want to model things fundamentally as one-way, lot of the SOAP spec. is slightly ambiguous on that. I would be happy to lay out some of the concerns since it ties into how we want to model RPC - think I can come up with a model.
SW: Can you put that on email?
HN: Yes – I will do that over the week-end – it should allow us to both have a concept of where RPC fits in and where other message exchange patterns like request-response fit.
SW: So Henrik you will take an action item on that?
HN Yes.
Work Item #3
SW: Item #3 re Protocol modules is large. There is a start in the AM document that addresses the whole area of message paths and handler targeting in MG’s thread - document tries to capture essence of MG’s thread - obviously incomplete - thread has petered out.
MG: It is not over yet.
SW: Also the contribution that Mark J. made is more formal - have to talk about incorporating that into the document - whether MJ work can be in a mature state by end of the month.
MG: If all that is resolved, will it speed things if we leave message path and targeting stuff out?
SW: MJ’s document is a useful start and we can leave it as placeholder – would like to hear what Mark’s ambitions are with his piece of work.
MJ: I made a recent submission last night – this is a slightly different version in which does a concept-by-concept comparison with SOAP – all the formal parts fall out of the concept.. the axioms to consider and we pick and chose among those some pieces are orthogonal – need to walk through with this group and decide what parts of that generality and functionality we want and don’t want and I can re-work.
MG: So everyone is to have read MJ document and digested by next week’s conference?
SW: Yes – how about a half hour at next week’s conference for Mark’s walk-through.
MH: Need more than half hour – it is quite a big piece of work.
MG: Mark’s recent version last night is quite short.
MH: But it has big implications.
MJ: There are also two pieces – second part is on attachments – that is very short.
SW: You might look at the Abstract model on attachments centered around binding.
MJ: The first abstract model diagram – blocks streaming through various handlers and some blocks being re-written, some blocks going all the way through and some blocks being introduced – there is another picture showing parallelism.
SW: Would anyone like to develop thoughts on faults and fault handling in intermediaries?
MH: Faults are tightly bound up with the message passing – should it be done separately?
MJ: There are quite a few questions about this – it is tied with the application of the handlers.
SW: So for the work items list I have it right that these three items are listed. Mark and Marc it looks like you may take some ownership of that piece.
MJ: I am certainly going to interact with the Module application because they may fault – there are different kinds of faults – should you then pass those cell blocks forward or pass them back – with composition, faults may pass directly into the module - but can the module handle faults or is it intended to pass faults on to some other module?
SW: There are some cycles going on in Work Item #3. Also Marc Hadley is participating in that discussion – so I will put Marc Hadley and Mark Jones names beside that item #3.
MH: We have been emailing back-and-forth.
MJ: My only caveat is it is hard to talk about fault handling without a Module application model. The two are bound together.
HN: Will talk with you (MH,MJ) if there are questions about what SOAP does – SOAP has a model for dealing with this – should start with modeling that.
MH: MJ’s proposal goes a lot further than SOAP – do we want to take on all that additional functionality or is SOAP functionality sufficient? That is a fundamental question as well.
SW: Let’s review next week after Mark’s session and perhaps target a longer timescale than end of March. Don’t want to discourage Mark’s contribution – an excellent piece of work
Work Item #6
SW: Work Item #6 Arbitrary attachments – Mark may have added a piece – also the on-going work of the ebXML Convergence Group is interesting re attachments. The Abstract Module document says we intrinsically handles attachment. I feel that’s enough…
MJ: Axioms and concepts in my document mainly deal with semantic issues like does it make sense to carry attachment nobody refers to and things like that…
SW: I was beginning to form that question myself. If you were able to construct a reference to attachments positionally – and to walk the message someway then you could potentially find them even without an explicit reference in the message
MJ: New blocks could come into existence at intermediaries - so there wasn’t a reference to it and now there is. Bizarre behavior potentially - We should at least talk about this.
SW: There is a piece in the glossary not well covered in the Abstract model which is the whole enveloping-header-body discussion – and outer wrappings like MIME wrapping. Is that something we need to cover somehow?
HN: It is a fundamental piece of the SOAP architecture - this composability model where things can just slide into a slot – this is the crux of the SOAP model – if we don’t follow this composability model then we should gone with another solution. Another AM model is not really there yet.
MH: Are you talking about slipping things into the SOAP header or actually slipping in extra MIME parts?
HN: The general case within the SOAP envelope is you can stick in as many headers as you like – and they can be targeted at specific things, nodes – in addition, because there are links, here is a module - the only thing the block actually does is to link off to some data and go get it.
MJ: In SOAP with attachments, can you add a block that has a link…or add a header that has a link to a new attachment and also add an attachment?
HN: Absolutely. It’s intended that way…
MJ: There can be an API that allows the module to interact with the transfer binding to get the attachment, add it in a way that doesn’t disturb the link already references an attachment and such. [????]
HN: That makes sense. Of course SOAP doesn’t enforce an API - you would have to do that.
SW: We had a discussion at the f2f about what a message was – we arrived at blocks-to-headers and body-to-envelope - now we have what is called the arbitrary attachments, parts we don’t necessarily want to carry in the outermost XML construct. In an abstract sense, what it the construct called that carries the whole thing?
HN: Doesn’t make sense to have a term for that construct - it is like saying does a Web page contain all the images it links to – or are they just references or semantics for the page.
SW: So your viewpoint is the outermost construct discussed is the XML envelope?
HN: We define a processing model for the XML constructs – not a processing model for what should be done with links – that is up to the applications – in the SOAP-with-Attachments spec it deliberately says a SOAP processor processes a SOAP envelope without acting on links – it doesn’t say the links have to be resolved and make sure the documents are there in the MIME multi-part and do something with them. That is up to the application. That would require semantic understanding of the link, why it is there, what does it point to - that is outside the scope of the basic XML construct. Another discussion is about differentiating between “local” URIs and “Global” URIs – i.e., local URIs point into the MIME multi-part - in practice that is impossible to make that distinction because URIs don’t work that way. So it is useful to say while links can be put into a SOAP envelope or XML protocol envelope, the envelope is what we care about – for the links the module semantics might say resolve this link and do something with this document- e.g., a digital signature to verify a document – i.e., application semantics.
SW: How would you discuss carrying arbitrary content in an XML protocol message?
HN: That is a protocol binding issue. If it is chosen to map it into a MIME multi-part – it is a binding issue since MIME multipart is a protocol binding – can also choose to bind into HTTP with HTTP URIs – can do others also.
SW: That is how the Abstract Model Section 6.2 treats it – as a binding issue.
MH: Are you saying we need a binding for HTTP with MIME and a binding for HTTP without MIME?
HN: The SOAP Attachment spec. defines a binding for HTTP – one can nest bindings so can have a MIME multi-part binding for SOAP saying this is how to stick a SOAP envelope into a MIME multi-part, but MIME multi-part is also not a protocol so have to stick somewhere else to actually transfer it – so have to nest protocol bindings: SOAP->MIME Multi-part->HTTP (that is defined) in SOAP. All rules for HTTP bindings are like any other binding – only difference is content.
MJ: Need an abstract model for talking about those pieces (content) of the message at that binding level so when you go through an intermediary where transports are changed, the processor would have a systematic way of inquiring of the first binding about all the parts of the message it contains (abstractly), getting it and telling the next binding it is your responsibility to carry these with these URIs – rather than having n-squared pieces of code that get this from this binding and stick it in this binding.
MH: Why we would do that – why wouldn’t XML protocol always be wrapped at outer level by MIME.
MJ: That is the ebXML solution – but people here don’t want to do that.
MH: I am new to the group – does anyone remember why we didn’t want to do that.
HN: MIME multi-part is not an appropriate binding – there are some properties not needed that should not be sent such as for small devices – the XML protocol message is the key – if it has a binding to something else fine, but if we want to stick the SOAP protocol message on top of TCP or UDP, e.g., then there is no need for MIME.
MH: MIME isn’t very heavyweight, only a few lines – to handle message maybe don’t want to fork off on what the MIME type is.
HN: Big set of problems – not just a set of lines, but different way to express parameters and bunch of things – doesn’t mesh well with XML.
MH: Where can I find those list of problems?
HN: Discussion with Mark Baker on Dist-App.
MH: Not much there – will discuss with Mark Baker.
Work Item #7
SW: Mapping between SOAP 1.1 and the Abstract Model – Does anyone have a sense on how to do that? This is one of David Fallside priority items.
MH: Mark Jones document at least starts to that, and how what he propose maps to SOAP.
SW: One way to do the mapping is to annotate throughout the Abstract Model document. – rather than gathering a document annex.
MH: That is worthwhile – readers are most likely already familiar with.
MJ: Useful to put concepts down in a list and address item one-by-one rather than paragraphs of prose that connect things together and not take apart the distinct concepts and assumptions – is it possible to re-visit model to add that as an addendum or weave into the text.
SW: Will incorporate work you did Mark, but have to maintain a style.
MJ: I could rewrite my stuff with a lot of prose and use an approach of listing the SOAP concepts as an alternative characterization that could be put into an appendix, then the rest of my document could be concepts associated with each section and then annotate those with the SOAP comparison and stick that in an appendix [????]
SW: Will ask David Fallside question of how he wants that mapping presented.
Work Items #8 and #9
SW: Work Items #8 and #9 which are Abstract Model mapping with the XML Protocol requirements in the Requirements document and the Design Scenarios within the Requirements document. SW reviewed assignments in <AMG Work Item table> above.
Issues at front of Abstract Model document
SW: Next agenda item is the Abstract Model issues list on Page 2 February 16 version – let’s run through them. <See Abstract Model Issues Table> above.
End of Call