[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: More Comments on MS V.941
Prasad, Please see my responses inline below. Cheers, Chris Prasad Yendluri wrote: > > christopher ferris wrote: > > > 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 > > Chris (et al), > > The spec needs to be explicit on the normative nature of the specification part or the > non-normative nature of the schema in the appendix. This is not stated. Currently it states that > the schema is normative as well (see lines 38-..) The schema IS normative with regards to the ebXML SOAP extension element definitions. What the schema does NOT cover (presently) is where these MUST be included in the SOAP Envelope. The normative part of the specification covers that. A schema validator will correctly validate an ebXML SOAP Message (the SOAP-Env:Envelope and its descendants). The problem with using XML Schema to extend by redefine is that the targetNamespace of the schema that redefines another MUST be the same as the targetNamespace of the schema being redefined. I'm still investigating this as a possible approach to address Yan's issue/concern. The only thing that the current schema (appendix A1) does not address from a validation perspective is where the ebXML SOAP Header and Body extension elements belong. One thing that Henrik indicated to us in our discussions in the SOAP sub-team was that for all intents and purposes, the SOAP Body element is just a specialized SOAP Header as far as a compliant SOAP Processor is concerned. He uses the term "syntactic sugar" to characterize the distinction between the two. From a processing POV, an ebXML SOAP processor can either: - respond with an Error if the message does NOT conform to the ebXML Message Service specification (e.g. because an element that is expected to be in the SOAP:Header is somewhere else such as the SOAP:Body) - Or, it can look around to see if the element (that otherwise conforms to the ebXML SOAP extension element schema) is present and process the message and its contents anyway. > > 38: *Appendix A Schema- This normative appendix contains [XML Schema] for the ebXML Header > document. > > Additionally, I noticed at least few places where the specification is not explicit on the > required/optional nature of elements and attributes (where as the schema captures is accurately). > This needed to be tightened up if the specification part (and not the schema) is the normative. If you are referring to the fact that in the specification, there are places where the word REQUIRED or MUST is used as regards an element or attribute definition and its cardinality, optional elements are expressed as MAY be present or without an explicit statement. This is because we have chosen to avoid use of the word OPTIONAL in the specification as it MAY be interpreted (incorrectly) by an implementor to mean "You need NOT implement" when in reality, it means "The element MAY be present, a compliant implementation MUST be prepared to handle the elements presence or absense and process accordingly". There is very little in the specification that is OPTIONAL to implement. > > The wording in the appendix needs to be updated to reflect that this is the schema for both SOAP > Header and Body extensions (lines 2015-2017): > > 2015: A.1 > 2016: The following is the definition of the ebXML SOAP Header extension elements as a schema that > > 2017: conforms to [XMLSchema]. Yes, I had a similar comment in the emails I just sent out with my comments. I agree. > > Regards, Prasad > > > > > > > > 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 > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC