Comments on ebXML Requirements document, 2000-1-4

[Henry Lowe <hlowe@omg.org>]

Hi,

The folowing are a few comments on the Requirements document 
that David circulated yesterday.  Sorry I can't put these 
comments in-line (for context), but I only have the PDF reader.  

Clause 1.1:
Requiring the transport to carry anything, either "XML or other 
electronic formats" seems to be leaving it up to the communicating 
applications to perform all conversions to deal with different, 
"endians", character sets, etc.  This would seem to be a lot of 
extra code required for applications.  I would suggest we deal 
only with XML which means that the transport value-add and deal 
with some of these common problems.  Do we want more than an 
ASN.1 ANY or octet string?

Clause 2.1:
Am I correct is reading this as a list of options the transport 
shall provide and does not require they always be in use?

Clause 2.1.b:
Who is the original sender?  If there are indirections at the 
application level, it would be too difficult for the transport 
to do this IMHO.

Clause 2.1.c:
Doesn't 1.3 above subsume this?  If not, I'm not sure I understand
this bullet.

Clause 2.1.d:
This would seem to be an implementation/operational requirement, not 
a transport specification requirement.

Clause 2.2.a:
This would seem to be very much dependent on 1.1.  If the transport 
is nothing but a conveyor of ANY(s), it knows nothing of the bits 
it's carrying and this requirement would seem unreasonable.  On the 
other hand, if the transport is providing a value-add for XML, there 
would be certain well-formedness checks that could reaonably be 
expected.  Might I suggest that this requirement is rather dependent 
on 1.1?

Clause 2.2.b:
Isn't this just non-delivery reporting?  If a reason code can be returned,
that would be an added bonus.

Clause 2.2.c:
Please see comment on 2.2.b.

Clause 2.2.d:
Unless I misunderstand this bullet, please see comment on 2.2.b.

Clause 2.3:
I believe this is an application concern, not a transport standard 
concern (an app which understands the business aspects would raise 
an error or exception?).

Clause 2.4:
This isn't always possible and you also want to differentiate between 
transport failures and application failures.

Clause 4:
In light of the footnote on 4.1.b, might I suggest we look at having 
separate requirements for Transport and Packaging?  It seems the items 
in Clause 4 are more (though not exclusively, e.g., 4.2.b would be 
transport) Packaging than Transport.

Clause 5.1 and 5.2:
Is this transport of Packaging?

Clause 5.3:
This goes way beyond what anything other than a very specialized 
transport could provide -- in a sense this is workflow (which CORBA 
does have -- work done cooperatively with WfMC).

Clause 5.4:
Would this be Packaging?

Clause 6.1:
Aren't these definitions, not requirements?

Clause 6.2:
These items would seem to be involve a combination of application, 
server, and transport -- they are not JUST transport requirements, IMHO.

Clause 6.4:
This would seem to be more application than transport, though the 
transport would certainly need to be able to provide the comm 
mechanism to convey the status query and response.

Clause 6.5:
I believe what this means to say is covered in 2.1 -- two phase commit 
transactional semantics (the sort of thing offered by CICS and OTS).

Clause 7.1:
This is very general (perhaps too general to be included here?).

Clause 7.2:
Great!!

Clause 7.3:
I would interpret this as saying that the right level of API must be 
available (and I would support this).  Also, the API should be language 
independent.  Is this the correct understanding?

Clause 7.4:
Isn't this covered by 7.2.a?

Clause 8.1:
Isn't this more a workflow type thing?  and not strictly transport?

Clause 8.2.a.footnote 5:
Couldn't we include CORBA in this list in case folk want an object 
oriented transport?  :-)

Clause 8.2.b:
This involves two phase commit transactional semantics which you 
probably don't want to require of all transports all the time, see 
comment on 2.1.  SMTP and HTTP do not provide this; however, CORBA 
does.

Hope these comments are useful is getting ready for Orlando.

Best regards,
Henry