See also: IRC log
<scribe> scribe: markphillips
<scribe> chair: Roland
- 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
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
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
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.[End of scribe.perl diagnostic output]