RE: missing(?) header element

["Burdett, David" <david.burdett@commerceone.com>]

I agree (yet again!!) with Chris's idea of a test/production indication in
the header. However we also need to define what a MSH should do when it gets
a "test" message.

Following the same line of reasoning, there are many other
elements/attributes that are in, for example RosettaNet that are not covered
in ebXML. Given that one of the original requirements was to enable ebXML
TRP to be the "bridge" between other transport protocols I think it would be
a good idea to do a gap analysis.

So a question for tomorrow morning's conference call ...
1. Do we really want to make ebXML a "briding" protocol
2. If we do, which protocols do we bridge to, and
3. Who/how do we do the gap analysis

David

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Wednesday, November 15, 2000 1:45 PM
To: ebxml transport
Subject: missing(?) header element


All,

This has been discussed previously, but now is the time
to revisit the issue of missing header elements starting
with the following proposal. 

This issue should be added to the comments list for v0.8.

I would propose that we add a new element to be used
to indicate whether the message is a test or live/production
message. Both RosettaNet and OTA have something similar
in purpose, although each calls it something different.
I imagine that other vocabularies have something similar
as well.

The purpose of this element (or attribute as the case may
be) is to enable parties to exchange messages prior to
actually engaging in e-business, to ensure that their
systems are prepared to correctly handle the messages
they send eachother.

I would propose that we add the following element as a
sub-element of Header:

	<!ELEMENT Usage EMPTY>

	<!ATTLIST Usage  Mode  (test | production )  #REQUIRED >

e.g.
	<Usage Mode="test"/>

I would propose that this Usage element be OPTIONAL in cardinality
within in instance document. It would be REQUIRED for a receiving
MSH treat the message as <Usage Mode="production"/> in the absence
of a Usage element within an instance document.

An alternate approach would be to add an OPTIONAL attribute
to the ebXMLHeader element:

	<!ATTLIST ebXMLHeader Mode (test | production) #IMPLIED>

or, specifying a default value:

	<!ATTLIST ebXMLHeader Mode (test | production) "production">

e.g.
	<ebXMLHeader xmlns="..." 
		MessageType="Normal" 
		Version="1.0" 
		Mode="test">
	...
	</ebXMLHeader>

As with the case of the Usage element above, if the attribute
is absent in an instance of an ebXMLHeader instance document,
a receiving MSH SHALL treat the message as if it had an attribute
of Mode="production". 

I could also live with:

	<!ELEMENT Usage EMPTY>

	<!ATTLIST Usage  Mode  (test | live)  #REQUIRED >

or, specifying a default value...

	<!ATTLIST ebXMLHeader Mode (test | live) "live">

It would be likely that we would need to specify explicitly
that a message sent in response to a message sent with Mode="test"
MUST itself have a Mode="test" and vice versa.

Comments?

Cheers,

Chris