Interop Matrix Feedback

Here's some feedback on the Interop matrix as requested during the last 
call.


Abstract schema types need not appear in the matrix. If the type hierarchy 
contains info
set items that are related to optional functionality,then this should be 
dealt with
on a per message basis.  Abstract types that appear in the matrix include
  - MessageAbstractType
  - RequestAbstractType
  - ResultType
  - KeyBindingAbstractType

Attributes that are required per schema need not appear in the matrix, e.g,
  - MessageAbstractType.Id attribute and
  - MessageAbstractType.Service attribute

Required attributes/elements for optional elements need not appear in the 
matrix e.g,
  - UseKeyWith, when used, requires both the Application and Identifier 
attributes.
  - TimeInstant, when used, requires the Time attribute

Exchange type specific attributes need not appear in the matrix, e.g.
  - If an implementation claims support for the two phase exhange type then 
support
    for the MessageAbstractType.Nonce attribute is implied.

Required (sub-)elements need not appear in the matrix, e.g.
  - If an implementation claims support for the Validate request/result 
message pair
    then support for QueryKeyBinding is implied, as this element is required 
in the request
    and support for KeyBinding is implied, as this element (while optional 
in the grammar)
    is required for cases where a key binding is to be returned.

Result elements need not appear in the matrix.
  - It is unlikely that an implementation will support, say, ValidateRequest 
while not
    supporting ValidateResult. It might be more meaningful to treat the 
requests and
    results as pairs as opposed to individually.

Since the Compound messages can contain messages from both XKRSS and XKISS 
it may be more
meaningful to deal with them indepent of service type (XKRSS/XKISS). Also, 
it might be
interesting to know what combinations of messages are supported by an 
implementation.

Exchange type (Synchronous, Asynchronous, Two-Phase) and bindings (e.g SOAP 
1.2, SOAP 1.1)
should be indicated on a per message basis as opposed to disjointly.

It might be meaningful to indicate the extent to which an implementation 
supports
KeyInfo in (at least) queries.

It might be meaningful to indicate the extent to which an implementation 
supports
RespondWith's in (at least) queries.

It might be meaningful to indicate the protocols (SMTP/HTTP) that an 
implementation
supports for notifcation mechanisms as part of the asynchronous processing
[PendingNotification.Mechanism].

Regards
Tommy

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Received on Tuesday, 22 June 2004 07:55:13 UTC