Re: DTD Restructure Proposal

[christopher ferris <chris.ferris@east.sun.com>]

Marty,

Comments squared below. Thanks for taking the time to review
the reworked DTD. These are great comments and will help
shape the discussion this week.

Cheers,
Chris

Martin W Sachs wrote:
> 
<snip/>
> 
> Flattening of the CPP:  While I have no technical problem with the proposed
> flattening, there is some understandability advantage to tags like
> <DeliveryChannelSet> which merely group related lower level tags in the
> same manner as intermediate directories in the hierarchical file system.  I
> don't know whether these container tags are advantageous or disadvantageous
> to processing of the CPP or CPA.  Is there any other disadvantage to them?

Well, they do add some processing overhead and they make xpath 
queries into the structure longer than they need to be. While there
is certain advantage to these tags in making the instance doc a little
easier to read for a human, they add no value to a machine;-)
I am of the opinion that a human would be interacting with a GUI
anyway and probably never see an instance document directly. Thus,
I removed them.

Note that in the case of ActionMenu, it now becomes possible
to specify a service and action pair as 
	Service[text() = "service"]/Action[text() = "action"]

as opposed to:
	Service[text() = "service"]/ActionMenu/Action[text() = "action"]

It may not seem like much, but the processing overhead can add up
quickly in a busy system.

> 
> <Participants>:  We need to discuss whether the address and contact
> information should be in the CPP/CPA or pointed to by them (perhaps at the
> CPP owner's private site).  If we do leave them in, some fields will need
> to be internationalized.

Agreed. I didn't do too much in that space.

> 
> <Certificate>:  <OrgCertSource> is related to self-issued certificates.
> Some people have complained that self-issued certificates are not currently
> usable due to problems with public key infrastructure.  In tpaML,
> <OrgCertSource> is intended only for digital envelope.

I have been struggling with this one. I didn't modify it, but I'm
thinking that it may need to be changed. Specifically, if there
is a "standard" vocabulary for Certificate, then I would like to
use that, rather than something which is non-standard. Secondly,
certs will be needed to be accessed from some external store. Possibly,
what is needed is the reference to that store, and the key identifier.
ANother possibility is that the certs themselves would need to 
be in ASN.1 form anyway. It isn't clear that an XML certificate
description is of any real use.

> 
> <Certificate>:  The cardinality should be 0 or more (*) since security has
> cardinality 0 or 1 (?) .
> 
> <Duration>:  date and time will need to be internationalized.

Agreed.

> 
> <Endpoint>:  We need to discuss why the endpoint information should not be
> put directly in the CPP/CPA. Since this uses CDF and HREF, an explanation
> of these facilities would be helpful.

Gladly.

> 
> <Endpoint>:  The transport endpoint information has to be installed into
> the parties' systems in order to enable them to communicate.  Just pointing
> to an external document isn't sufficient as a definition.  The format of
> that document has to be specified in detail just as if the information were
> inside the CPP/CPA so that an installation tool can correctly parse it and
> install the contents.  Similarly, a CPA composition tool has to understand
> the contents of the endpoint documents to determine if they are compatible
> and how to build the CPA if that information is to be incorporate into the
> CPA.  (NOTE:  Compatibility may not be an issue since the endpoints
> currently consist only of communication addresses.  Compatibility can be
> determined by comparing the delivery channel definitions in the two CPPs.)

Note that the Endpoint doesn't point to an external document. It is
the URI through which the endpoint is accessed. I think you misconstrued 
the meaning I had for this field.

> 
> <Logon>:  This tag contains <UserId> and <Password>. The DTD shows that
> <Logon> is required if password authentication is chosen.  In tpaML,
> <Logon> is optional and there is a strong warning not to use it. The reason
> is that there are security concerns when a password is included in the CPA
> or CPP, even if it is intended only as a first-time password to be changed
> immediately.  My personal preference is to delete <Logon> altogether (in
> which case the initial passwords would be exchanged through a secure
> channel, e.g. a phone call).  At least we should make <Logon> optional and
> retain the warning against using it.

I too had reservations about leaving in Logon. We should discuss.

> 
> <CertificateAuthentication>:  This tag is in the 0.3.1 DTD but not in the
> 0.3.1 XML file.

Yeah, XMLAuthority doesn't always output optional elements when
you generate an instance document.

> 
> <Certificate>:  In the 0.3.1 DTD, <Certificate> is under
> <CertificateAuthentication>.  In the 0.3.1 XML file, it is under <Member>.
> Chris' covering email says that it goes under <Member>.

Yes, if we do keep Certificate in the CPA/CPP, then I think that they
should be enumerated under Member and referenced elsewhere since
it is likely that they'll be "reused".

> 
> <MessageEncoding>:  Missing from the 0.3.1 DTD, present in the 0.3.1 XML.
> 
> <MessageRetries>:  This seems to have been subsumed into
> <ReliableMessaging>.  However the intention of <MessageRetries> in tpaML is
> to support retry of application-level errors (exception responses).  We
> should retain it in the CPP/CPA specification.  Placing it under
> DocExchange in tpaML was purely a guess because some of these error
> conditions are actually reported by DocExchange middleware.  However I
> believe that it would be equally acceptable to place it directly under
> <BusinessProtocol> or <Service>.
> 
> <CertificateReference>:  What is supposed to be in the #PCDATA field?

Actually, what I had in mind was an empty tag with an IDREF to the
Member/Certificate. I'll take another look.

> 
> <Channel>:  In tpaML, the original intent was that there is one for the
> entire TPA, which did not have to be identified in the business protocol
> section, or multiple channels which could either be assigned to individual
> actions or selected dynamically by the runtime.  This proposal adds a
> channel ID to <Service>. This permits a separate channel ID for each
> service.
> 
>     We need to agree on the meaning of ChannelId in <Service>.  Most
>    likely, it defines the delivery channel to be used for the whole
>    Service; if a channel ID is stated in an action (commercial transaction)
>    definition, that overrides the channel ID of the whole service.

Agreed. In fact, we may simply want to limit complexity by
having a single delivery channel for a Service and leave it at that.

> 
> <Channel>:  We need to come to agreement on the unidirectionality or
> bidirectionality of a channel.  For HTTP synchronous operations, a channel
> is bidirectional.  For asynchronous actions (commercial transactions), in
> the current BP team proposal, a channel is also bidirectional since
> responses are not separate from the request in the same commercial
> transaction.  In tpaML, a response is an action request in the other
> direction, hence the channels used with tpaML actions are really
> unidirectional.  If we decide that the actual delivery path is
> bidirectional, we have a decision to make.  One possibility is that a
> delivery channel represents the owner's receive capabilities only.  In that
> case, the CPA actually has to contain pairs of delivery channels and the
> channel ID in the CPA Service or Action (commercial transaction) has to
> point to a matched pair of channels (i.e. a tag encompassing one delivery
> channel for each party).  Alternatively, we can decide that a delivery
> channel in a CPA includes both parties' receive capabilities.

Yes, one thing I have not added (yet) is some means of describing
send capabilities. IN a CPA, it would (seem to) be unnecessary. However,
in a CPP, it is certainly required.

> 
> <TerminateConversation>.  In tpaML, this identifies an action which ends a
> conversation.  This will be replaced by the corresponding construct in the
> XML generated by the BP Specification Metamodel.

I left in all of the tpaML BP stuff as optional if a reference to
an external BP is not used.

Once we integrate the BPM stuff from the BP team this week,
it is possible that all of the tpaML BP stuff can be removed.
Of course, we could make it <!ELEMENT ... ANY>  which would make
the tpaML BP stuff valid as well.

> 
> <ServiceSecurity>:  In tpaML, this provides a default message security
> option (yes or no) for the entire Service.  This will be replaced by the
> corresponding construct in the XML generated by the BP Specification
> Metamodel.
> 
> <Comment>:  In tpaML, this was intended as a place which could be used to
> identify an associated paper contract without attracting lawyers' attention
> :-).  We should provide some way of identifying the paper contract, perhaps
> be a more meaningfully named tag.

Good point!

> 
> *************************************************************************************
> 
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> *************************************************************************************
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard