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: [ebxml-msg] Re: New Schema


David:

Thanks for your feedback. Please see my comments inline and the
attached XSD file. I will wait for the schema to stabilize before
requesting Jeffrey Lomas to post it again.

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 6:35 AM
Subject: RE: New Schema


>Thanks Arvola, and thank you for the comments.  I will work through them
today.
>
>I notice some things in the new schema
>
> the tns name needs to be updated with your new name.

Agreed.

> In MessageHeader, From, To, CPAId, ConversationId, Service,
> Action, MessageData are required

That's already the case. An element is required unless there is a
minOccurs="0" clause.

> In MessageData, MessageId and Timestamp are required

Already no minOccurs="0" specified.

> DeliveryReceiptRequested instead of DeliveryReceiptAckRequested

Agreed.

> duplicateElimination should be boolean not tns:boolean

Agreed.

> remove tns:id and tns:version on TraceHeaderList (it's inside Via)

Agreed.

> need a tns:version attribute on Error

Since Error is a sub-element of ErrorList and the latter already has a
tns:version attribute, I don't think a tns:version attribute is needed at
the
Error level. Do you agree that the convention is to have a version
attribute only for children of soap:Header and soap:Body?

> Service & Action have been removed from Via

Agreed.

> DeliveryReceipt & Acknowledgment, RefToMessageId is required

Already no minOccurs="0" specified.

> soap:actor on AckRequested and Acknowledgment need defaults (ToPartyMSH)
> does this mean they are not required?

I am adding http://www.oasis-open.org/committees/ebxml-msg/ToPartyMSH as
default for the actor attribute in AckRequested and Acknowledgment.

I am also adding http://www.oasis-open.org/committees/ebxml-msg/nextMSH as
default for the actor attribute in Via.

Please note that I am using www.oasis-open.org instead of oasis-open.org to
be consistent with what are already in the message header schema. This is in
conflict with sections 2.2.10 and 2.2.11.

Yes, if a default is specified for an attribute, then that attribute can be
omitted.

> remove rmm.type

Agreed.

> remove signedUnsigned.type

Agreed.

> add Role child element to From and To

Agreed.

>
>I think most of this stuff is just being picky.  Looks really good.
>
>Thanks again,
>
>David.
>
>-----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.x
s
>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.
>
>

draft-msg-header-02.xsd



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


Powered by eList eXpress LLC