[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] RE: New Schema
With SOAP, you cannot rely on having schema validation at the receiving end. It isn't clear that we have indicated otherwise for ebXML, but I don't see how we can change the rules of SOAP. Therefore, you cannot rely on defaulting values from the schema through schema processing/validation. You *can* say that the absence of an attribute MUST be interpreted as having a meaning equivalent to what is specified as the default value... Cheers, Chris David Fischer wrote: > OK. . .if SOAP:mustUnderstand can be set to "false" then I don't have any > objection. Isn't that the default if it does not appear? > > David. > > -----Original Message----- > From: Arvola Chan [mailto:arvola@tibco.com] > Sent: Wednesday, October 24, 2001 11:18 AM > To: David Fischer > Cc: ebxml-msg@lists.oasis-open.org > Subject: Re: [ebxml-msg] RE: New Schema > > > David: > > >> h.. Section 6.1 should include a SOAP mustUnderstand attribute and show >>the requirement/optionality of each attribute. >><df>No. See next comment</df> >> >> i.. Section 6.2 should indicate that DeliveryReceipt has a required SOAP >>mustUnderstand attribute. >><df>No. We don't want to stop a message just because we don't understand >>DeliveryReceiptRequested. Let's reserve errors/SOAP:Fault for real errors. >> > I > >>have no problem with sending back a "not supported" error with severity of >>"warning" as long as the message goes on.</df> >> >> o.. Section 8.3 is missing the version and SOAP mustUnderstand attributes >>and statement about the requirement/optionality of attributes. >><df>I see version? Why have a SOAP:mustUnderstand on the reply? Not that >> > it > >>would hurt anything.</df> >> > > We need to be consistent with the discussion in section 2.2.5 about the > requirement to have a mustUnderstand attribute in all extensions to > soap:Header. The DeliveryReceiptRequested, DeliveryReceipt, and > StatusResponse elements are all "SOAP bubbles" and should have > the mustUnderstand attribute. Since this is a boolean attribute, it can be > set to false so that receipients who don't understand the corresponding > extensions can safely ignore them. > > Regards, > -Arvola > > -----Original Message----- > From: David Fischer <david@drummondgroup.com> > To: Arvola Chan <arvola@tibco.com> > Cc: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org> > Date: Wednesday, October 24, 2001 8:05 AM > Subject: [ebxml-msg] RE: New Schema > > > <df>comments in-line</df> > > Regards, > > David Fischer > Drummond Group. > > -----Original Message----- > From: Arvola Chan [mailto:arvola@tibco.com] > Sent: Tuesday, October 23, 2001 7:23 PM > To: David Fischer > Cc: ebxml-msg@lists.oasis-open.org > Subject: Re: New Schema > > > David: > > I have updated the message header schema and requested the web master to > post the file > > http://www.oasis-open.org/committees/ebxml-msg/schema/draft-msg-header-01.xs > d > > (Please see the carbon copy message to the ebxml-msg alias of my request to > Jeffrey Lomas if the posted file is not yet assessible.) > > In the course of this exercise, I have found a number of inconsistencies in > the 1.05 draft. Sections 2.2.7 (id attributes -- I think this should be > renamed id attribute to be consistent with the sibling sections), 2.2.8 > (version attribute), 2.2.9 (SOAP mustUnderstand attribute) indicate that the > id attribute is optional, the version attribute is required, and the SOAP > mustUnderstand attribute is required. I am assuming that the above rules > apply only to ebXML extension elements that are the immediate children of > SOAP:Header. Thus, it is OK for the Manifest element not to have a SOAP > mustUnderstand attribute. Similarly, since TraceHeaderList is not a child of > SOAP:Header, its version attribute would not be required. > > <df> Yes, change attributes to attribute -- our convention has been to say > REQUIRED in the text when it is required and not to say anything when > optional. > I won't guarantee that we are consistent on this.</df> > > Based on the above assumptions, I suggest the following clarifications and > editorial changes to the spec: > a.. Sections 2.2.10 and 2.2.11 should indicate that the SOAP actor > attribute is used only in the AckRequested, Acknowledgment, and Via > elements. > <df>Someone may extend the spec and use this attribute.</df> > > b.. Always list the attributes id, version, mustUnderstand, and actor > (where applicable) in front of all other elements or attributes when > describing an extension element. > <df>Agreed</df> > > c.. For each SOAP module, consistently reiterate that the id attibute is > optional, the version attribute is required, the SOAP mustUnderstand > attribute is required. > <df>If you follow the links, this is already apparent. Why say the same > thing > over again?</df> > > d.. Section 3.1.6.4 should indicate that the TimeToLive element is > optional. > e.. Section 4.2.2 should indicate the requirement/optionality of > attributes. > f.. Section 4.2.2.2.5 should indicate that the location attribute is > optional. > g.. Section 4.2.2.2.6 should be renamed xml:lang attribute. The attribute > should be indicated as being optional. > <df>Agreed</df> > > h.. Section 6.1 should include a SOAP mustUnderstand attribute and show > the requirement/optionality of each attribute. > <df>No. See next comment</df> > > i.. Section 6.2 should indicate that DeliveryReceipt has a required SOAP > mustUnderstand attribute. > <df>No. We don't want to stop a message just because we don't understand > DeliveryReceiptRequested. Let's reserve errors/SOAP:Fault for real errors. > I > have no problem with sending back a "not supported" error with severity of > "warning" as long as the message goes on.</df> > > j.. Section 6.2.2 should indicate that the Timestamp element is required. > <df>Agreed</df> > > k.. Section 7.3.1 should indicate the requirement/optionality of > attributes in AckRequested. > <df>Follow the links. Since SOAP:actor has a default, I don't think it is > required. Same comments below</df> > > l.. Section 7.3.3 should indicate the requirement/optionality of > attributes in Acknowledgment. > m.. Section 7.3.3.3 should indicate Timestamp is required. The required > RefToMessageId element should be described after Section 7.3.3.3. > <df>Agreed</df> > > n.. Section 8.2 is missing a SOAP mustUnderstand attribute and statement > about the requirement/optionality of attributes. > <df>Agreed.</df> > > o.. Section 8.3 is missing the version and SOAP mustUnderstand attributes > and statement about the requirement/optionality of attributes. > <df>I see version? Why have a SOAP:mustUnderstand on the reply? Not that > it > would hurt anything.</df> > > p.. There used to be Service and Action elements under Via. Why are they > missing from section 11.1? > <df>When we took CPAId off of Via we took Service and Action with it.</df> > > In general, I would prefer to see a clear indication of the > requirement/optionality of each sub-element/attribute, in the overview > description of an element, rather than inferring that information from the > subsequent descriptions. > <df>If everyone agrees to this change, I will go through and change > everything.</df> > > -Arvola > -----Original Message----- > From: David Fischer <david@drummondgroup.com> > To: Arvola Chan <arvola@tibco.com> > Date: Tuesday, October 23, 2001 12:26 PM > Subject: New Schema > > > Arvola, > > Since the group voted to accept v1.05, could you go ahead and > validate/post the new schema (I tried to make the appropriate changes)? > > Thanks, > > David Fischer > Drummond Group. > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC