Re: More Comments on MS V.941

[Yan Guo <yguo@webmethods.com>]

If we have the definition for the ebXML TRP extension of soap:Header and
soap:body in ebXML TRP schema, then the issues like "Manifest" should be in
soap:body  can be enforced by the standard XML schema validation engine.
Thus there is no need for one to write special validation engine for ebXML
TRP envelope. This would be a big win for the ebXML users.

-Yan

----- Original Message -----
From: "christopher ferris" <chris.ferris@east.sun.com>
To: "Yan Guo" <yguo@webMethods.com>
Cc: "Ebxml" <ebxml-transport@lists.ebxml.org>; "Prasad Yendluri"
<prasad.yendluri@webMethods.com>; <marcb@webMethods.com>
Sent: Friday, March 09, 2001 8:59 AM
Subject: Re: More Comments on MS V.941


> Yan,
>
> The specification is normative. That means that if the specification
> says that the manifest MUST appear in the SOAP:Body, that it MUST.
> How this is enforced is outside the scope of the specification.
>
> Cheers,
>
> Chris
>
> Yan Guo wrote:
> >
> > I believe the way of extending soap:header and soap:body by restriction
is
> > the only correct way. Otherwise, e.g.,  how can we express the fact that
> > "Manifest" element should really be in soap:body element, and not in
> > soap:header element.
> >
> > -Yan
> >
> > > Yan,
> > >
> > > There are a couple of different ways that we could represent the
> > > schema for TR&P. One is the way we have expressed in the current
> > > draft of the spec. The other would be to import the SOAP
> > > schema and extend by restriction the SOAP Header and Body elements.
> > >
> > > Either way is valid as I understand.
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > > Yan Guo wrote:
> > > >
> > > > It seems to me that the schema for the ebXML Envelope in the TRP
v0.98
> > are
> > > > missing the definition for the extensions of soap:Header and
soap:body.
> > Is
> > > > this true ?
> > > >
> > > > Yan Guo
> > > > webMethods, Inc.
> > > >
> > > > ----- Original Message -----
> > > > From: "Rik Drummond" <rvd2@worldnet.att.net>
> > > > To: "Munter, Joel D" <joel.d.munter@intel.com>; "'Burdett, David'"
> > > > <david.burdett@commerceone.com>; <dick@8760.com>; "Ebxml"
> > > > <ebxml-transport@lists.ebxml.org>
> > > > Sent: Thursday, March 08, 2001 9:57 AM
> > > > Subject: RE: More Comments on MS V.941
> > > >
> > > > > does .98 take care of your issue? if not let us know... rik
> > > > >
> > > > > -----Original Message-----
> > > > > From: Munter, Joel D [mailto:joel.d.munter@intel.com]
> > > > > Sent: Wednesday, March 07, 2001 11:26 AM
> > > > > To: 'Burdett, David'; 'dick@8760.com'; Ebxml
> > > > > Subject: RE: More Comments on MS V.941
> > > > >
> > > > >
> > > > > where can i go to get a latest copy of v0.941 and the related
schema?
> > the
> > > > > private page only lists v0.92.
> > > > > thanks,
> > > > > joel
> > > > >
> > > > > -----Original Message-----
> > > > > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > > > > Sent: Tuesday, March 06, 2001 3:46 PM
> > > > > To: 'dick@8760.com'; Ebxml
> > > > > Subject: RE: More Comments on MS V.941
> > > > >
> > > > >
> > > > > Dick
> > > > >
> > > > > As we are using XML Schema, technically, we have to conform to the
XML
> > > > > Schema rules.
> > > > >
> > > > > David
> > > > >
> > > > > -----Original Message-----
> > > > > From: Dick Brooks [mailto:dick@8760.com]
> > > > > Sent: Sunday, March 04, 2001 8:36 AM
> > > > > To: dick@8760.com; Ebxml
> > > > > Subject: More Comments on MS V.941
> > > > >
> > > > >
> > > > > line 684 - There is no description of the date/time format to use
in
> > > > > Timestamp. I propose adding the following text to line 684:
> > > > >
> > > > > "The format of CCYYMMDDTHHMMSS.SSSZ" is REQUIRED to be used. This
time
> > > > > format is Coordinated Universal Time (UTC)."
> > > > >
> > > > > ----
> > > > >
> > > > > line 685 - I'm confused by the occurrence of SequenceNumber in the
> > > > > RoutingHeader. Does the
> > > > > SequenceNumber in a RoutingHeader take precedence over
> > > > > a SequenceNumber located in the QualityOfServiceInfo? What is the
> > > > > relationship of the
> > > > > two sequence numbers?
> > > > >
> > > > > At the risk of assuming too much I suspect the SequenceNumber
element
> > in
> > > > the
> > > > > Routing Header is instructing an
> > > > > intermediary the order to process messages, relative to the
message
> > > > exchange
> > > > > between sender and intermediary.
> > > > > The Sequence Number in the Routing Header is not connected to the
> > > > > QualityOfServiceInfo/SequenceNumber associated with the original
> > > > application
> > > > > message.
> > > > >
> > > > > Personally, I would prefer to remove the SequenceNumber element
from
> > the
> > > > > RoutingHeader in order to eliminate any potential for issues
regarding
> > the
> > > > > two SequenceNumber elements.
> > > > >
> > > > > ----
> > > > > line 710 is missing the <PartyId> element
> > > > > ----
> > > > > line 711 is missing the <PartyId> element
> > > > > ----
> > > > > line 712 - missing <CPAId>
> > > > > ----
> > > > > line 715 - incorrect URN for the content of MessageId, the correct
URN
> > is:
> > > > > mid:29dmridj103kvna
> > > > > ----
> > > > > line 725 contains an invalid Timestamp format, correct format is
> > > > > CCYYMMDDTHHMMSS.SSSZ
> > > > > ----
> > > > >
> > > > > Examples at lines 735-778 all have the same set of issues as
stated
> > above
> > > > in
> > > > > lines 710, 711, 712, 715, 725
> > > > > ----
> > > > >
> > > > > lines 780-792 - it's not clear what the UnSigned and None values
are
> > used
> > > > > for. Are these vestigial from a previous incarnation of the
document?
> > They
> > > > > don't appear within the contents of section 12, nor within the XML
> > DSIG
> > > > > spec.
> > > > > ----
> > > > >
> > > > > Still reviewing, more to come later.
> > > > >
> > > > >
> > > > > Dick Brooks
> > > > > Group 8760
> > > > > 110 12th Street North
> > > > > Birmingham, AL 35203
> > > > > dick@8760.com
> > > > > 205-250-8053
> > > > > Fax: 205-250-8057
> > > > > http://www.8760.com/
> > > > >
> > > > > InsideAgent - Empowering e-commerce solutions
> > > > >
> > > > >
> > > > > ------------------------------------------------------------------
> > > > > 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
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org