comments on TA,v0.8

[Christopher Ferris <chris.ferris@east.sun.com>]

Anders & Team,

Here are my comments on the TA,v0.8 spec. I'm not positive
that the line numbers will match up because I've used StarOffice
to apply line numbers... Anyway, here goes.

Cheers,

Chris

General

w/r/t the words SHALL, MUST, ... the usual convention is to CAPITALIZE
these words or phrases in the body of the document wherever they have
been used according to the definition expressed in RFC2119. There are
numerous places within the body of the document where this is not
the case.

please run spellcheck;-)

Section 5.2 - this is still a set of requirements, not an architecture
description. If the intent is to provide the RegRep team with some
requirements, please do this separately and keep the Architecture
document an architecture and NOT a requirements document.

line 208 - you are providing examples of 'Repository Authority' before
defining the term. The term is also not identified as a term which is
expressed in the Glossary (which is bold if I correctly interpret
the convention). Also, shouldn't it be 'Registry Authority'?

line 332 - is the term 'data element' synonymous with 'repository object'?
if so, please use the term 'repository object' for consistency.

line 335 - the example does not match the text above. If the 'data element'
or 'repository object' is addressable via an URL with an XPointer then
the syntax of the query would be more like:

	http://foo.org/<somepath>/[code = '<somecode>']

or possibly:

	http://foo.org/<somepath>/getStuff.cgi?query=/somecontextpath/[code = '<somecode>']

The form of the example given is merely an HTTP query.

line 591 - it is not clear to me that the MS layer enforces the rules
expressed in the TPA. It certainly uses these rules, but in fact, the
TPA's BP rules would NOT be enforced within the Messaging Service layer.

line 593 - ... maps an ebXML message onto the ...
			     ^^^^^^^

line 596-598 - I think that we are nearly in complete agreement within
TR&P that a set of normative transport protocol bindings/mappings will
be a deliverable of the TR&P Messaging Services specification. This 
sentence is therefore incorrect.

line 641 - some of the 'parameters' necessary to send an ebXML message
are derived from the TPA which is identified in the Header.

line 643 - Receive doesn't indicate willingness as much as it is
a function which accepts incoming ebXML messages for processing.

line 662 - change 'behavior each party agrees to abide by.'
	to 'behavior by which parties agree to abide.'

line 762 - change 'agnostic' to 'neutral' or some other term

line 775 - to identify what?

line 785/786 - refer to Messaging Service specification.

line 791 - same comment as 785/786

line 819/821 - it would seem to me that if a participant were to
utilize its own repository, that the registry would simply have
a pointer to the repository object(s) and would not submit them
to the repository. 

line 819/821 - it would seem that the whole set of steps related
to the context-based assembly of the messages to be exchanged
according to the business process needs to be described here
before we move on to the TPP stage.

line 829 - this step is premature IMHO. Before an exchange of 
messages can take place, the following steps must be processed:

	- Party A retrieves Trading Partner Profile (TPP) of Party B
	from registry
	- Party A combines its own TPP with that of Party B resulting
	in a configuration which may be used to enable the exchange of
	messages (TPA)
	- Party A communicates the resultant TPA to Party B and if
	accepted, may begin exchange of ebXML messaging after each
	party has installed the resultant TPA
	- The TPA may be registered with the Registry (this is
	not mandatory, but probably a useful means of enabling
	a unique identification of the TPA between the two parties)

Note that there is a negotiation process involved here which should
be expressed as a business process (in terms of the BPM) and which 
could be either a manual or automated process facilitated by ebXML
Messaging Service. If automated discovery/negotiation, then some manner
of bootstrapping must be provided which enables a previously unknown
party to send a message which can be accepted for processing. This
would likely take the form of an anonymous TPA (TPA Template) which 
is installed in the Messaging Service of the target party (Party B)
which is registered in a Registry/Repository...

line 863-876 - this describes a nirvana case where an enterprise has a
fully ebXML-enabled application suite. I think that we need to 
express the terms of the architecture such that it is demonstrated
to support "legacy" applications, etc. We will NEVER be successful
if we do not make this case EXPRESSLY and ABUNDANTLY clear to all
who read these specifications!!!!! 

line 887 - change 'have to' to 'MUST' for clarity









-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903