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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic-conform message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [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

Refering to
They shall have the same value

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
Has the same situation

Would there be any value in just making one encoding test requirement,
MIME Header and XML Prolog ? It seems these 2 test requirements are covering
the same situation. Just spelled out differently.
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 ?
  ^--- 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
It would also give you an escalting test scenario in the test driver itself
or reuse of test artifacts.
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.
The DuplicateElimination element [must|is] not [be|] present.
[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)
fvalue => value
MessageIde => MessageId
An Acknowledgement Message is generated with RefToMessageId having the
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
[... AND the syncReplyMode is [not] set to none ...]
{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]
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.
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
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.

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.

[... AND attribute status="Continue" (if attribute status is present?)]
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.

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 ?


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