[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Fw: Please post (msg-header-2_0.xsd)
I agree with Arvola's reading here,
but I don't think the text is badly ambiguous.
Whether you have "perMessage or "always" for
DuplicateElimination, the sending MSH needs
to include the DuplicateElimination element,
and that is what the text says. The additional
words do help to clarify the situation, though,
and I think they would be helpful to implementers.
-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Monday, January 14, 2002 12:52 PM
To: Doug Bunting; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Fw: Please post (msg-header-2_0.xsd)
Doug:
I don't quite agree with your statement:
>At the moment, a Receiving MSH has the
>option (a poor word meaning interoperability problem) of checking the
CPA
or
>always not doing duplicate elimination when DuplicateElimination is not
>present. A Sending MSH has the option of including or leaving out the
>DuplicateElimination element when the CPA says "always". Our document
>should specify one approach and avoid the two MSH having to come to yet
>another agreement.
At least, I don't think that is our intent. My assumption has been that
the
receiving MSH must always check that the incoming message is consistent
with
the CPA (or configuration parameters). If the CPA indicates "never", the
DuplicateElimination element must not be present. If the CPA indicates
"always", the DuplicateElimination element must be present. This
behavior is
consistent with our treatment of the AckRequested element.
Perhaps Section 7.4.1 is a little bit ambiguous:
"The DuplicateElimination element MUST be used by the From Party MSH to
indicate whether the Receiving MSH MUST eliminate duplicates (see
section
7.6 for Reliable Messaging behaviors). If the value of
duplicateElimination
in the CPA is never, DuplicateElimination MUST NOT be present."
My interpretation of the the first "MUST" in the above statement is that
the
sender must include a DuplicateElimination element if its desires the
elimination of duplicates. It will be helpful if we also explicitly
state
that this is permissible only if the duplicateElimination attribute in
the
CPA is either "always" or "perMessage". Conversely, it would be
inconsistent
for the sending MSH to include a DuplicateElimination element if the
duplicateElimination attribute in the CPA is "never".
Regards,
-Arvola
-----Original Message-----
From: Doug Bunting <dougb62@yahoo.com>
To: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
Date: Monday, January 14, 2002 11:09 AM
Subject: Re: [ebxml-msg] Fw: Please post (msg-header-2_0.xsd)
Arvola,
You've described the distinction between the CPA and the message format
quite well. Unfortunately, the document remains unclear in a closely
related area: It doesn't tell anyone what should be in a message if the
CPA
says duplicateElimination="always". Ignoring the confusion between
describing the semantics of a core module in the Additional Features
part of
the document, section 7.4.1 doesn't include Dan's good words about how
the
CPA and message instance should be compared. Of course, these words
should
be changed to reflect our later decision avoiding "idempotent" in the
document.
Dan's message may be found at
http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00195.html
With this addition, we'd describe how both duplicateElimination="never"
(already in the document) and duplicateElimination="always" drive the
Sending MSH. Both would result in direct control of the
DuplicateEliminiation element in the message and result in Inconsistent
errors when that control is ignored. At the moment, a Receiving MSH has
the
option (a poor word meaning interoperability problem) of checking the
CPA or
always not doing duplicate elimination when DuplicateElimination is not
present. A Sending MSH has the option of including or leaving out the
DuplicateElimination element when the CPA says "always". Our document
should specify one approach and avoid the two MSH having to come to yet
another agreement.
thanx,
doug
----- Original Message -----
From: "Arvola Chan" <arvola@tibco.com>
To: "Ahmed Zahid" <zahid.ahmed@commerceone.com>; "David Fischer"
<david@drummondgroup.com>
Cc: <ebxml-msg@lists.oasis-open.org>
Sent: Friday, 11 January 2002 19:27
Subject: Re: [ebxml-msg] Fw: Please post (msg-header-2_0.xsd)
In the CPA, there is a duplicateElimination attribute that can take on
the
values "never", "always", or "perMessage".
If it is "never", that means the two parties have agreed that
duplication
elimination should never be done. In that case, the ebXML message MUST
not
include a DuplicateElimination element.
If it is "always", that means the two parties have agreed that
duplication
should always be done. In that case, the ebXML message MUST always carry
a
DuplicateElimination element.
If it is "perMessage", then the application may determine on a per
message
(actually per conversation) basis whether duplicate elimination should
be
carried out.
The presence of the DuplicateElimination element indicates that
duplicate
elimination is desired. There is no need for any additional attribute
within
that element.
Regards,
-Arvola
----- Original Message -----
From: "Ahmed, Zahid" <zahid.ahmed@commerceone.com>
To: "'Arvola Chan'" <arvola@tibco.com>; "David Fischer"
<david@drummondgroup.com>
Cc: <ebxml-msg@lists.oasis-open.org>
Sent: Friday, January 11, 2002 7:12 PM
Subject: RE: [ebxml-msg] Fw: Please post (msg-header-2_0.xsd)
> Another question:
>
> In the msg-header-2_0.xsd schema, DuplicateElimination
> is defined as:
>
> <element name="DuplicateElimination">
> </element>
>
>
> However, there is no duplicateElimination attribute
> defined for it to take the values: "perMessage" or
> "always".
>
> Amy I missing something?
>
> E.g., is this really an omisison in the latest
> schema. if yes, I suggest following modification of
> the msg-header-2_0.xsd schema:
>
> <element name="DuplicateElimination">
> <simpleType>
> <restriction base="string">
> <enumeration value="perMessage"/>
> <enumeration value="always"/>
> </restriction>
> </simpleType>
> </element>
>
>
>
> thanks,
> Zahid
>
> Zahid Ahmed
> Commerce Security Architect
> Commerce One, Inc.
> 408/517-3903
>
> -----Original Message-----
> From: Arvola Chan [mailto:arvola@tibco.com]
> Sent: Monday, January 07, 2002 8:11 AM
> To: David Fischer; ian.c.jones@bt.com
> Cc: ebxml-msg@lists.oasis-open.org
> Subject: [ebxml-msg] Fw: Please post (msg-header-2_0.xsd)
>
>
> David and Ian:
>
> Should I ask Jeff to create a
>
> http://www.oasis-open.org/committees/ebxml-msg/doc
>
> directory as the home directory for the spec document? I can ask him
for
> the passwords for the schema and doc directories so that we can
maintain
> the files in these directories directly.
>
> Regards,
> -Arvola
>
> -----Original Message-----
> From: Jeffrey Lomas <jeff.lomas@oasis-open.org>
> To: Arvola Chan <arvola@tibco.com>
> Date: Monday, January 07, 2002 6:46 AM
> Subject: Re: Please post (msg-header-2_0.xsd)
>
>
> >Arvola,
> >I posted the document you requested. While on the server I noticed
that
> the
> >ebxml-msg TC is set up to maintain its committee pages itself. This
means
> >that whoever has the user name and password to the ebxml-msg ftp
directory
> >can post documents to the schema directory. Let me know if I can
ever be
> of
> >assistance.
> >
> >Regards,
> >Jeffrey Lomas
> >OASIS
> >
> >Arvola Chan wrote:
> >
> >> Jeffrey:
> >>
> >> Please post the attached file to
> >>
> >>
http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd
> >>
> >> Thanks,
> >> -Arvola
> >>
>
-----------------------------------------------------------------------
> -
> >> Name: msg-header-2_0.xsd
> >> msg-header-2_0.xsd Type: unspecified type
> (application/octet-stream)
> >> Encoding: quoted-printable
> >
>
>
> ----------------------------------------------------------------
> 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