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


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>



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


Powered by eList eXpress LLC