Loading ...
Sorry, an error occurred while loading the content.

Round 3 results Discussion Summary and other tidbits

Expand Messages
  • Rebecca Dias
    My apologies for taking so long to post the discussion results. Nimbda and I were fighting :(. I had a lot of fun the last week. The group inspired me to be
    Message 1 of 2 , Mar 3, 2002
      My apologies for taking so long to post the discussion results.  Nimbda and I were fighting :(.
      I had a lot of fun the last week.  The group inspired me to be a consumer and promptly go and buy a wifi network for my house on Saturday.  If anyone has experience with overheating radio cards, let me know.  I can't stay on the network more than 2 minutes before the linksys wireless card overheats and freezes my Toshiba laptop.  And I am dying to sit on my porch in the rain with an internet connection.

      For the Next Host:
      1 room for everyone otherwise they will revolt :)
      100 Base T and Wifi is a good combo
      Phil likes pizza with no cheese :)
      Two cases of Diet Coke are needed, one with lunch and one 3 hours later.
      Everyone in the group will come an hour early and stay 3 hours late.

      I wanted to extend the right to anyone who continues actively to participate in the SOAPBuilders Interoperability Forum(in both the face to face meetings and discussions on the SOAPBuilders newsgroup) to use the Logo that IONA's design department made for the event.  www.xmlbus.com/interop.
      I posted a history of SOAPBuilder Interop at http://www.xmlbus.com/interop/overview/, please review it and let me know if I am misguided anywhere.
      ******* Keith, I was not able to clearly articulate the namespace issue you brought up.  See what happens when you become useless :(
      ******* 4 Encoding Styles
      Cross Reference the Discussion which has already started... "Subject line: [soapbuilders] rpc/literal and wrapped doc-lit"
      Some companies have never bothered to implement RPC Literal.  Why?
      Is it possible to marry RPC Encoded and Doc Literal?
      Does it make sense to get rid of the encoding quadrant and focus solely on RPC Encoded and Doc Literal.  Most agree that Doc Literal would be the preferred encoding style and ideally it would be best to fix Doc Literal to properly support graphs, references, and linked lists.  If schema matured to support graphs, RPC Encoded would not be needed.

          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



      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'

    Your message has been successfully submitted and would be delivered to recipients shortly.