OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [ebxml-msg] RE: New Schema


David:

Sections 2.2.7, 2.2.8 talk about required attributes in ebXML SOAP extension
elements. We must be consistent about the requirement of these attributes
when we describe individual extension elements.

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: Thursday, October 25, 2001 6:50 AM
Subject: RE: [ebxml-msg] RE: New Schema


I am confused, why would there be a SOAP:mustUnderstand on DeliveryReceipt
or
Acknowledgment, those are the replies.  Why wouldn't they only be on the
DeliveryReceiptRequested and AckRequested?  I am still questioning the need
on
DeliveryReceiptRequested but I think it is OK if the value is "0".

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