Re: [ebxml-msg] RE: New Schema

[Martin W Sachs <mwsachs@us.ibm.com>]

Please see my comments below, labelled MWS:

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



David Fischer <david@drummondgroup.com> on 10/24/2001 11:04:24 AM

To:    Arvola Chan <arvola@tibco.com>
cc:    ebxml-msg@lists.oasis-open.org
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>

  MWS:  The specification must be precise as to when each attribute
  or element is used. In particular, the text must always agree with
  the Schema.
  If someone wants to extend the spec later, they
  must modify the text accordingly.

  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>

MWS:  Please stick to the previous convention of not using the words
OPTIONAL and NOT REQUIRED; these create problems because RFC2119 defines
them as "need not be implemented". In the CPP-CPA spec, we adopted the
convention of using the "DTD" attribute or element type in order to avoid
saying OPTIONAL or NOT REQUIRED.

-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>