Comments and Suggestions - 0.9a

[Michael Joya <mike.joya@xmlglobal.com>]

lines 496-499:
    CPAId element: What values go in this element during an anonymous
query? Before you obtain CPA or CPPs from a registry, you have to be
able to query the registry. To query the registry, you need a CPAId.
This circular dependency infers predetermined knowledge before online
contact. Anonymous messages are the starting point of an important
bootstrap/discovery process and should be addressed.
   Suggestion: Predefine an 'anonymous' CPAId to allow for discovery.
I recommend a text node value of "anonymousQuery" within a CPAId to
represent a blank-slate CPA for guest users and bootstrap capability.
You may have reason to use a URI instead. Ideally there should be a
pre-defined CPP document(s) outlining the required capabilities of a
client using guest access, but in the absence of a hard CPA schema, a
placeholder CPAId would do.

lines 514-519:
     Service element: Again, what are the valid range of values. Is this
range of values ebxml-defined, implementor-defined or
application-defined? If I wish to use a type attribute instead, what is
the valid range of arguments to this attribute value?
    Suggestion: Dictate that all application and/or implementor defined
services use URIs to ensure global uniqueness. Services that are
ebxml-defined should have reserved type attribute values, ie:
type="registry".
    Suggestion: Provide a small inline example for a combination
Service/Action element combo.

lines 661-675:
    Multihop Transmission 1 example: If I understand this correctly, (A)
wants to send a message to (C) through (B). (A) does not specify (C)'s
receiverURI at any point in transmission1. How does (B) obtain (C)'s
receiverURI? Is it a requirement of the MSH Layer in (B) to map the <To>
field from the header into a <ReceiverUri> for transmission2? (B) seems
to obtain this data out of thin air.
    I still do not see the overrall value of multihop messaging other
than for proxy purposes. Is this the only purpose?
    Suggestion: Either dictate where party B should obtain the
ReceiverURI from (note: this is Not an implementation detail; A and B
are seperate parties!), or allow A to communicate it to B in
transmission1.

line 765:
    default value given for codeContext attribute: There is nothing
wrong with this line! Hurray for default values!
    Suggestion: more lines like this!


    The underlying theme here is that each data element given in the
specification that does not lend itself to an arbitrary range of values
SHOULD have at least one of:
  a) a default value
  b) an acceptable range, pattern, or 'source' of values to choose from
  c) a reference to a specification outlining valid values

     Also helpful would be mention of which role, (ebxml, msh-server,
msh-client, application-service, application-client) is to validate and
which is to provide. This is not always clear except for in examples.

- mikej