<scribe> scribe: markphillips

<scribe> chair: Roland

First Public Draft

- has been approved - should be published next week

Roland: xml schema has issued last call for 1.1 - SOAP/JMS WG has been invited to review it. In terms of relevance to SOAP/JMS this means checking that string, long, int, boolean, and anyURI are still appropriate for our use

Eric: xsd:string may encompass a wider set of characters

<scribe> ACTION: markphillips to review the relevant parts of the XML Schema draft on behalf of SOAP/JMS WG [recorded in http://www.w3.org/2008/07/15-soap-jms-minutes.html#action01]

<trackbot> Sorry, couldn't find user - markphillips

Testing the Assertions in the spec.

Roland: How would we use the assertions as the basis for validating implementations of the spec.

alewis: + Phil: No updates since last discussion

Phil: Need to agree to what extent we need to implement the test suite. Does it need to be a packaged turnkey test suite for the vendors

Roland: We need to validate that it is possible to build (multiple) implementations of this spec.
... e.g. does not need automation in the base test suite

alewis: Who will provide the SOAP/JMS implementations? How will we provide the implementations? Which service provider will we run over?

Roland: We do not have to provide the implementations - we just create the test suite

alewis: We need to prove the test suite as well as the spec. and we need vendor implementations to demonstrate the test suite

Phil: How do we prove the spec. using the test suite?

Roland: If we have multiple implementations that produce the correct outputs according to the test suite, then we have demonstrated that the spec can be implemented

<Yves> http://www.w3.org/2005/10/Process-20051014/tr.html#cfi

Roland: The W3C process does not require that vendors demonstrate interoperabililty - just that the implementations implement the spec. (see above link )

<Yves> http://www.w3.org/2005/10/Process-20051014/tr.html#cfr

<Yves> [[

<Yves> Shown that each feature of the technical report has been implemented. Preferably, the Working Group should be able to demonstrate two interoperable implementations of each feature. If the Director believes that immediate Advisory Committee review is critic

<Yves> al to the success of a technical report, the Director may accept to Call for Review of a Proposed Recommendation even without adequate implementation experience;

<Yves> ]]

<Yves> basically the WG has to define what interoperable means, and how it will be tested

alewis: The specification basically asserts what goes through various API calls to exchange JMS SOAP messages

Derek: We could meet w3c requirements with a get-together - even a virtual get-together

Roland: We do not need to get together face-to-face to test w3c requirements (though that might be useful for interop. testing). It would be enough to share the results of our tests
... Testing that WSDL is interpreted correctly *is* in scope

alewis: Support for WSDL is optional - how can this be in scope

Roland: Where products support WSDL we must check that they have implemented it according to the spec.
... The WSDL section(s) must not remain in the final version of the specification unless it has been tested by at least one implementation

Next version of specification

Roland: The WG charter states that we should have a last call by September 2008

This does not need to include coompletion of testing, but by the time we get to the Candidate Recommendation then we should have implementations

Still outstanding :

Phil made a suggestion on how we could add a non-normative description of the JMS API

Roland has addressed the nits that Eric identified

Eric has some work to detail what we mean be fully supporting the URI

<Roland> http://lists.w3.org/Archives/Public/public-soap-jms/2008Jun/att-0029/00-part

RESOLUTION: with reference to the email linked above - we do not need to add any more statements on ContentType and encoding of XML - testing / specifying the XML parser is outside the scope of these tests

http://lists.w3.org/Archives/Public/public-soap-jms/2008Jun/0031.html

Proposed JMS fragments

Phil: For each property, the proposal (linked above) outlines the different JMS methods required to set the property

Roland: Do we need to list all methods for setting a property, or just give one example?

Eric: Suggest we just show a single example.

Discussion whether we should avoid use of the word 'may' or 'should' because they imply RFC2119 compliance (because this is informative not normative)

alewis: We SHOULD NOT use ambiguous synonyms for RFC2119 terms
... These words must be uppercase as per RFC2119

<peaston> I have to leave, signing out

Roland: We should state that these examples are non-normative

<scribe> ACTION: Roland to check how we should make the disctinction between normative and non-normative [recorded in http://www.w3.org/2008/07/15-soap-jms-minutes.html#action02]

<trackbot> Created ACTION-15 - Check how we should make the disctinction between normative and non-normative [on Roland Merrick - due 2008-07-22].

markphillips: We should stick to JMS 1.1 API's - not use the TopicPublisher

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: markphillips
Inferring ScribeNick: markphillips
Default Present: alewis, Roland, +1.781.999.aaaa, peaston, Derek, Yves, +1.650.454.aabb, markphillips, eric, Phil
Present: alewis Roland +1.781.999.aaaa peaston Derek Yves +1.650.454.aabb markphillips eric Phil
Agenda: http://lists.w3.org/Archives/Public/public-soap-jms/2008Jul/0011.html
Got date from IRC log name: 15 Jul 2008
Guessing minutes URL: http://www.w3.org/2008/07/15-soap-jms-minutes.html
People with action items: markphillips roland

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.