OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic-interop message

[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