[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-iic-interop] [ebxml-iic-conform] TestReqs Comments
Well as many times as I have read the ebMS document, it seems you truly never know it. I have to commend the authors on the annotated ebMS spec for the thorough highlighting and the test requirements generated from it. Translating specification speak to actual test requirements is not always obvious. Upon review here's some comments, questions and corrections I've found. Page 3 (Test Requirements Doc) Table Fields ... "Name: A unique name for the Test Requirement." these ids have identical names 73,74 158,159,160 163,164,165 ================================== Refering to urn:semreq:id:10 Assertion They shall have the same value annotated_ebms_v2_0.doc 576-578 If provided, the MIME charset attribute MUST NOT contain a value conflicting with the encoding used when creating the SOAP Message My understanding of the specification is that you can list different value encodings, as long as the encodings are compatible (I don't think they're are many such possibilities, but the spec authors didn't disallow it) If an implementation were to have different encoding values but one is a compatible subset of the other (e.g. UTF-8 and ASCII). How would this test requirement play out in the testing driver. According to the assertion they would fail, but they would be in compliance with the spec ? Refering to urn:semreq:id:18 Has the same situation Would there be any value in just making one encoding test requirement, covering MIME Header and XML Prolog ? It seems these 2 test requirements are covering the same situation. Just spelled out differently. ----------------------------------------------- urn:semreq:id:37 What determines if a conversationID is out of context ? The CPPA 2.0 lists concurrentConversations and invocationLimit is this what the test requirement aludes to ? Also what is the error to generate ? (The spec doesn't say the error code to use ?) ------------------------------------------------ Would it provide value to list test requirement dependencies ? e.g. urn:semreq:id:79 ^--- urn:semreq:id:77 ^--- urn:semreq:id:78 They struck me as building up from each other. So you could say urn:semreq:id:78 is Ack was not received plus (urn:semreq:id:77 testrequirement) ... It would also give you an escalting test scenario in the test driver itself or reuse of test artifacts. ----------------------------------------------- urn:semreq:id:104 May want to spell it that Reference is "XMLDsig Reference" element and not "ebXML Manifest Reference" element. urn:semreq:id:105 is more clear concerning the reference - another possibility is to switch 104 & 105 so the XML Signature is listed first. --------------------------------------------- urn:semreq:id:110 Suggestion: The DuplicateElimination element [must|is] not [be|] present. --------------------------------------------- urn:semreq:id:130 PreCondition: [Suggestion for clarity - the phrasing was little hard to follow] (For each reliably received message, having a SOAP actor URI targeting the receiving MSH and the AckRequested element is present) Assertion: [Correction] fvalue => value MessageIde => MessageId [Suggestion] An Acknowledgement Message is generated with RefToMessageId having the MessageId value of the message being acknowledged. -------------------------------------------------------- urn:semreq:id:137 & 138 (dangling quote) I think you meant to enclose "original message" 138: "Acknowledgement Message" or just remove the end quote -------------------------------------------------------- urn:semreq:id:141 PreCondition: [... AND the syncReplyMode is [not] set to none ...] ----------------------------------------------------- urn:semreq:id:142 PreCondition: {this must have been a tough one to decipher - back to boolean algebra :&) [... AND [if] the syncReplyMode is [not] set to none and the CPA indicates that an application response is NOT to be included] ----------------------------------------------------- urn:semreq:id:145 remove this one ? I wonder if we should include this one - while the spec says it - it has no meaning for testing purposes. I mean hell I could fedex you a error log and that would satisfy the specification requirement. Doesn't really offer any value - this is more like a documentation item for say implementation guidelines. ------------------------------------------------------ urn:semreq:id:150 dangling quote ------------------------ urn:semreq:id:150-151 should be combined (they are both required together) urn:semreq:id:152 (is there a need to differentiate first message versus reset as far as the assertion (status="reset" and sequenceNumber="0" ) they are the same test. seems like all 3 could be just one testrequirement - I don't see any reason to make the semantic difference highlighted when the test is identical. ---------------------------------------------------------------------- urn:semreq:id:153 Remove this requirement I understand ebMS2#9.1.1 that status="reset" is with the sequenceNumber="0" only in cases 1 & 2 and not the numbers following it. And thus is the same as 152. ------------------------------------------ urn:semreq:id:154 Assertion: [... AND attribute status="Continue" (if attribute status is present?)] ----------------------------------------- urn:semreq:id:155 It implies there should be an error if this is not the case, but the spec doesn't say it. It would seem the receiving MSH would throw back an error - like illegal reset or hold the communication open until it's clear to reset. I think the test requirement covers the specification as written- but I think the specification missed something here. --------------------------------------------- urn:semreq:id:186,187,188,189,190,192,193,194,195 [PreCondition] an party => a party 188,189,190, 192,193,194,195,198 (redundant "the the") 191 messaged => message --------------------------- Couldn't urn:semreq:id:196 be a generic test requirement that all optional features that are unsupported must prove this assertion ? ----------------- urn:semreq:id:206 GenerateAckBasedBasedOnActor Should Based be repeated ? ------------------------------ That's all I found on this pass - phew - lots of stuff here ;)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC