[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Re: New Schema
Yes, you are right -- then delete tns:id. David. -----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Wednesday, October 24, 2001 11:03 AM To: David Fischer; Doug Bunting; ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Re: New Schema David: Since Error is a sub-element of ErrorList and the latter already has a tns:version attribute, I don't think it is necessary for Error to also have the same attribute. Regards, -Arvola -----Original Message----- From: David Fischer <david@drummondgroup.com> To: Arvola Chan <arvola@tibco.com>; Doug Bunting <dougb62@yahoo.com>; ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org> Date: Wednesday, October 24, 2001 7:30 AM Subject: RE: [ebxml-msg] Re: New Schema Yes, I agree but it needs a required version attribute. Regards, David Fischer Drummond Group. -----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Tuesday, October 23, 2001 8:18 PM To: Doug Bunting; ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Re: New Schema Doug: Thanks for pointing out the problem. I was assuming that there would be a subsection to describe each of the attributes listed in section 4.2.2.2.1. I essentially forgot that the Error element content also need to be described. It brings up one other issue in the schema. I like to propose to change the declaration of the Error element from <element name="Error"> <complexType> <attribute ref="tns:id"/> <attribute name="codeContext" type="anyURI" use="required"/> <attribute name="errorCode" type="tns:non-empty-string" use="required"/> <attribute name="severity" type="tns:severity.type" use="required"/> <attribute name="location" type="tns:non-empty-string"/> <attribute ref="xml:lang"/> </complexType> </element> to <element name="Error"> <complexType> <simpleContent> <extension base="string"> <attribute ref="tns:id"/> <attribute name="codeContext" type="anyURI" use="required"/> <attribute name="errorCode" type="tns:non-empty-string" use="required"/> <attribute name="severity" type="tns:severity.type" use="required"/> <attribute name="location" type="tns:non-empty-string"/> <attribute ref="xml:lang"/> </extension> </simpleContent> </complexType> </element> to allow for the content of the Error element to be a (possibly empty) string. Thanks, -Arvola -----Original Message----- From: Doug Bunting <dougb62@yahoo.com> To: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org> Date: Tuesday, October 23, 2001 5:55 PM Subject: Re: [ebxml-msg] Re: New Schema Arvola, On a very, very quick read, most of your comments seem reasonable. However, (g) doesn't sound correct because that section primarily discusses the content of the Error element and that content isn't described elsewhere. Perhaps we need a separate section on the xml:lang attribute and its semantics. When we create that section, we'll have to decide whether or not the attribute is required. I don't think we've ever made an explicit choice beyond accepting the schema as is (usually without detailed checks of that document). In general, I think you're making a good suggestion we'll have to implement in two steps: 1) confirm / decide on optionality (fill in the required / optional gaps you've left below and confirm your choices otherwise) 1a) go through all of the places in the specification where the document is ambiguous and the schema is specific 1b) decide whether or not the schema is correct 2) make necessary changes (executing on what you describe below) 2a) either update the specification or the schema depending upon our decisions in (1) This probably won't be too ardorous if we can batch the decisions neatly. thanx, doug ----- Original Message ----- From: "Arvola Chan" <arvola@tibco.com> To: "David Fischer" <david@drummondgroup.com> Cc: <ebxml-msg@lists.oasis-open.org> Sent: Tuesday, 23 October 2001 17:23 Subject: [ebxml-msg] 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. 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. 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. c.. For each SOAP module, consistently reiterate that the id attibute is optional, the version attribute is required, the SOAP mustUnderstand attribute is required. 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. h.. Section 6.1 should include a SOAP mustUnderstand attribute and show the requirement/optionality of each attribute. i.. Section 6.2 should indicate that DeliveryReceipt has a required SOAP mustUnderstand attribute. j.. Section 6.2.2 should indicate that the Timestamp element is required. k.. Section 7.3.1 should indicate the requirement/optionality of attributes in AckRequested. 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. n.. Section 8.2 is missing a SOAP mustUnderstand attribute and statement about the requirement/optionality of attributes. o.. Section 8.3 is missing the version and SOAP mustUnderstand attributes and statement about the requirement/optionality of attributes. p.. There used to be Service and Action elements under Via. Why are they missing from section 11.1? 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. -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> ---------------------------------------------------------------- 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