[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] ebXML Message Service Specification
I'd probebly try to steer clear of use of the "default" namespace. This is one of the aspects of namespace handling that is pretty screwed up IMO. I think that if we are going to use different namespace identifiers, that the examples should be fully qualified so as not to make things unnecessarily confused. That means that the namespace declaration needs to be part of the example. Cheers, Chris David Fischer wrote: > Actually, in this case, I think it would be prudent not to be consistent so as > not to create a "standard". I actually think it would be helpful to make some > of the examples use default namespace declarations rather than prefixing > everything with eb:. > > Regards, > > David Fischer > Drummond Group. > > -----Original Message----- > From: Arvola Chan [mailto:arvola@tibco.com] > Sent: Friday, October 26, 2001 10:05 AM > To: Christopher Ferris > Cc: ebXML Msg > Subject: Re: [ebxml-msg] ebXML Message Service Specification > > > Chris: > > You are correct. I was just trying to make everything look consistent. > The examples within the spec use "SOAP-ENV" whereas the > schema uses "soap". > > -Arvola > > -----Original Message----- > From: Christopher Ferris <chris.ferris@sun.com> > To: Arvola Chan <arvola@tibco.com> > Cc: ebXML Msg <ebxml-msg@lists.oasis-open.org> > Date: Friday, October 26, 2001 7:50 AM > Subject: Re: [ebxml-msg] ebXML Message Service Specification > > > Arvola, > > What possible benefit is to be gained from changing the namespace > prefix from SOAP to SOAP-ENV other than to add an additional 4 characters > to each namespace prefixed SOAP element in our examples? > > The value of the namespace prefix is not important except that it > match exactly the prefix used in the xmlns declaration of the document > in which the namespace qualified elements and attributes appear. > > Cheers, > > Chris > > Arvola Chan wrote: > > >>David: >> >>Please see the attached Word document for the contexts of the following >>comments. >> >>Regards, >>-Arvola >> >> >>-------------------------------------------------------------------------- >> > -- > >>---- >> >>Figure 1 needs to be put into the same format as other figures in this >>specification. The current figure seems to have very poor resolution. >> > Also, > >>the box labelled "Authentication,authorization and repudiation services" >>should be renamed "Authentication, Authorization and Non Repudiation >>Services". >> >>Incorrect figure number. >> >>We use the prefix SOAP-ENV to represent the SOAP namespace in the >> > examples, > >>but use the soap:prefix in the schema. Should we make these uniform? >> > Should > >>I change the schema to use SOAP-ENV instead of soap? >> >>The TimeToLive element may be specified for a Best-Effort message. The >>corresponding semantics need to be explained in this section. >> >>Strike this out in accordance with Marty's suggestion regarding the use of >>RFC2119 keywords. >> >>The ';' is extraneous. Should mechanism be plural? >> >>Since you are adding the canonicalization transform, doesn't that raise >> > the > >>total number of transforms to 3? >> >>This paragraph seems to be left over from an earlier version of the spec. >> > It > >>is no longer quite relevant because (1) TraceHeaderList is now a >> > sub-element > >>of Via and (2) the Acknowledgment element targeted for the next MSH will >>also be excluded by the transform. >> >>If this transform is always used, then one intermediary can never return a >>meaningfully signed (intermediate) Acknowledgment to another, because such >>an intermediate Acknowledgment will have an actor attribute value equal to >>the nextMSH and therefore be excluded from the signature. >> >>The third ds:Transform. >> >>The result of this transform is to canonicalize... >> >>Why are you combining the XPath transform with the canonicalization >>transform? In the 1.0 spec, an algorithm of >>"http://www.w3.org/TR/1999/REC-xpath-19991116" was used for the XPath >>transform. >> >>The spelling of soap needs to be in uppercase to be consistent with the >> > rest > >>of this example. >> >>This section should explain how a delivery channel is selected for a given >>error condition. >> >>This restriction seems unnecessarily severe. A DR may be piggybacked on a >>business message that asks for DR. The restriction should be applicable >> > only > >>when a DR message is sent on its own. >> >>The two sentences in this paragraph contradict each other. Some rephrasing >>is necessary. >> >>This part of the sentence is kind of circular. Suggest rephrasing as: >>"Reliable Messaging defines an interoperable protocol such that two >> > Message > >>Service Handlers (MSH) can reliably exchange messages using >> > acknowledgment, > >>retry, and duplicate detection and elimination mechanisms, resulting in >> > the > >>To Party receiving the message Once-And-Only-Once. >> >>This overview should mention duplicate elimination as a component of >>reliable messaging. >> >>This restriction should only be applicable when an Acknowledgment message >> > is > >>sent on its own, not being piggybacked on a business response message. >> >>I don't think it is appropriate to reference a subsection within another >>optional module. >> >>Will there be retries if the AckRequested element is not present? >> >>I am not sure if the Retries parameter should govern retries due to >>communication errors. In the RosettaNet Implementation Framework, retries >> > of > >>PIP actions due to the non receipt of acknowledgment is distinct from >>retries due to communication failure. >> >>This sentence is problematical. The behavior described below should only >> > be > >>exhibited by a Receiving MSH when it is the toPartyMSH! >> >>I think the pointer should be to section 7.5.3. >> >>This discussion really belongs in section 7.5.3. >> >>This should always be true because the antecedant in item 2 above is: "If >>the message is not a duplicate". >> >>This discussion belongs in section 7.5.3. >> >>The format of the Heading 2 paragraph style needs to be adjusted >> > (globally) > >>to provide more spacing between the section number and the section title. >>The attribute value "hanging" needs to be increased. It was not meant to >>deal with a document with so many sections. >> >>duplicateElimination is an attribute of QualityOfServiceInfo. >> >>This statement is not true for a Best-Effort multi-hop message. There will >>not be an AckRequested element in such a message. >> >>Is being returned? >> >>We need to make sure that the CPP/A can model these combinations. >> >>The format of the Heading 1 app paragraph style needs to be adjusted >>(globally) to provide more spacing between the appendix label and the >>appendix title. >> >>I suggest that this sentence be struck out. The schema must be in sync >> > with > >>the specification because implementers will directly use the schema in >> > their > >>implementations. >> >>-----Original Message----- >>From: David Fischer <david@drummondgroup.com> >>To: ebXML Msg <ebxml-msg@lists.oasis-open.org> >>Date: Thursday, October 25, 2001 7:18 AM >>Subject: [ebxml-msg] ebXML Message Service Specification >> >> >>I have been trying to capture the editorial comments as they come in. We >>are >>starting to get duplicates which indicates it is time to put out a new >>version. >>Tracking is on and Arvola's schema has been inserted. >> >>Regards, >> >>David Fischer >>Drummond Group. >> >> >>ebMS_v1.06.doc >> >>Content-Type: >> >>application/msword >>Content-Encoding: >> >>BASE64 >> >> >> > > > > ---------------------------------------------------------------- > 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