There were two potential solutions to fixing Doc Literal

    1) Work with the Schema working group to fix schema to support graphs; however, risk that the Schema group may not do it and take a long group of time.  "Would not happen before Schema v2.0 i.e. over ~1.5 years." - Alexander Falk

    2) Work with SOAP (XMLP) working group to address encoding issues.   Add an extension to Doc Literal to support this

Action Item: What is the proposal to solve the graphing problem?

Keith to attempt to make a proposal on the graphing problem 3/8/2002

Action Item:  Find and review current discussions on Schema and graphs.  Noah Mendelson had strong arguments for why SOAP encoding is a good thing.

    Glen to point SOAP Builders to this discussion.

What is the canonical way to represent the following datatypes

Counter representation for Hash tables

Graphs

Question from MS.  Who is going to release support for SOAP v1.2 on Last Call

    .NET plans to release as a beta release.

****** Intermediaries

Paraphrase of Glen Daniel's question to the group

    Do you feel that it is important to have the intermediaries as described as core SOAP.  Might be possible to represent Actor and intermediary as an extension to the spec.  MustUnderstand 1 with Actor attribute to insure that the message goes to the target endpoints.  E.g. A cell phone that has a hard wired SOAP endpoint doesn't need the overhead of routing, etc.  MustUnderstand would need to be there.   If you process a header, you are expected to follow the rules to do so.

Decouple it to make them progress at different rates.  If it is standardized and has quarks and needs updating, it makes it easier.

Summary of response to the question - If most companies have not yet implemented support for intermediaries, it is difficult to determine if the specification is implementable or needs to be tweaked in minor ways.  Having it as an extension will make it easier to bring it forward at its own pace.

****** WS-I

What is the relationship to WS Architecture Group

What is the relationship to SOAP Builders

            WS-I is a spec aggregator.  "What does it mean to our customers when we implement a Web service within a certain profile e.g. the green boxes in Interop Roadmap"

            SOAP Builders insure that the technology works.

            WS-I is a higher level set of test standards and tests.  Customers care that technology works, not how it works. WS-I builds profiles and test suites for customers to check to see if their apps meet these profiles.

            Pick narrow profiles and test to see if a WS is in fact a "WS"

            SOAPBuilders builds the underlying infrastructure to enable them to accomplish this.

            Everything is self-certified.  I assert that I pass these tests.  Here are the tests, here are my services.  You verify.

******* Futures, Scope, Roadmap -  (See attachment)

Next Round will be completely online showing SSL Interop.  Timeframe?

More WSDL Interop is needed.

Meet again within 3 months.

Keith - Dont use DIME for boxcaring, use it for pipelining.

Microsoft will not support SOAP with Attachments. We will only support DIME.  Biztalk may support it.

(XRML v2.0 Contact Gaurd - Xerox Park BPML)  is Dead W3C Signed SOAP (Note)

Disco/WSIL and ASD are now WS-Inspection

XKMS - Rich Salz - We see it as a way to federate our signing servers.  In the signatures we can put links to the server that did the signing and the encryption.

SOAP w/ Attachments over FTP and SMTP work inefficiently and cant work over IP.

keep codin'