RE: Manifest Element??

[Scott Hinkelman <srh@us.ibm.com>]

David B,

A few additional thoughts on the manifest errors ...

1. What should the MSH do if there is no manifest yet there is a payload
(and vice versa): a) ignore it, b) report a "warning" or c) report an
"error"
<SRH> Report an error. It is ebXMLMalformed.this is assuming we are not
specing
a no-payload message to mean something.

2. What do the MSH do if the manfiest is present but is inconsistent with
the payload entries again: a) ignore it, b) report a "warning" or c) report
an "error"
<SRH> Report an error. It is ebXMLMalformed.

Currently the spec does not define the behavior ...

Another thought is that with SOAP you could have "payloads" within the SOAP
body. Do we allow this, and if we do should we point to it from the
manifest.

Not close to the detail of SOAP alignment work, -> let me coin it the
"ebXML SOAP Profile",
I would think ebXML would make claim to the SOAP body for representing
appropriate ebXML header info only,
and mandate that ebXML Payloads ride as attachments and point via the
standard ebXML manifest..........?.........

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Robert Fox <robertf@softshare.com> on 02/23/2001 09:36:57 AM

To:   "'Burdett, David'" <david.burdett@commerceone.com>,
      ebxml-transport@lists.ebxml.org
cc:
Subject:  RE: Manifest Element??



Manifest entries should be used to look for and sync up payload, but I
would
think the sender needs to know that payload is being ignored because of a
bad or missing manifest.

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Friday, February 23, 2001 12:11 AM
To: ebxml-transport@lists.ebxml.org
Subject: RE: Manifest Element??


A few additional thoughts on the manifest errors ...

1. What should the MSH do if there is no manifest yet there is a payload
(and vice versa): a) ignore it, b) report a "warning" or c) report an
"error"
2. What do the MSH do if the manfiest is present but is inconsistent with
the payload entries again: a) ignore it, b) report a "warning" or c) report
an "error"

Currently the spec does not define the behavior ...

Another thought is that with SOAP you could have "payloads" within the SOAP
body. Do we allow this, and if we do should we point to it from the
manifest.

Thoughts?

David

-----Original Message-----
From: Rik Drummond [mailto:rvd2@worldnet.att.net]
Sent: Thursday, February 22, 2001 2:20 PM
To: ebxml-transport@lists.ebxml.org
Subject: RE: Manifest Element??


the question is: which is the most KISS'able?  rik

-----Original Message-----
From: Michael Joya [mailto:mike.joya@xmlglobal.com]
Sent: Thursday, February 22, 2001 3:51 PM
To: ebxml-transport@lists.ebxml.org
Subject: Re: Manifest Element??


  In answer to Robert Fox's post regarding the Manifest element, Doug
Bunting
writes, "It requires receivers to support both expressions of that
semantic."
He goes on to say that "some receivers could attempt to differentiate
leaving
out the Manifest element from an empty Manifest, thereby losing
interoperability with senders that use those two things interchangeably."

  The two different semantics are not in such conflict. Sure, there's a
difference between the absence of a Manifest element and an empty one. Take
the
"Table of Contents" approach (as expressed in my previous email.) The MSH
is
really concerned with the inner Reference elements that correspond to the
MIME payload envelopes. The Manifest, empty or absent, does not affect how
many
References are available. A robust implementation should be tolerant of
both
cases.

  Whether this is an ideal circumstance is open for debate. What purpose
requires a functional differentiation between an absent Manifest and an
empty
one? I cannot envision one.

  On a side note, I think the "POC request for fewer optional
elements" regarded the StatusData and ApplicationHeaders elements, but
that's a
separate discussion altogether.




--
// Michael Joya
// XML Global Research and Development
// 1818 Cornwall Ave. Suite 9
// Vancouver, Canada
// 604-717-1100x230




------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org