| Reference |
Submitter |
Comment |
Source |
|
|
| Sect 8.2
para 5 |
Mike Leditschke |
change 'to he' to 'to the' |
email
dated 10/1 |
|
| Sect 8.3 |
Mike Leditschke |
replace '???' with reference |
email
dated 10/1 |
|
| Section
8.4.4 |
Mike Leditschke |
text and schema (A.2) refer to
an attribute but example uses an element |
email
dated 10/1 |
|
| Appendix
A.2 |
Mike Leditschke |
Schema needs a targetNamespace
attribute of
"http://wwwebxml.org/namespaces/messageHeader" |
email
dated 10/1 |
|
| Appendix
B.1 |
Mike Leditschke |
Example uses a default namespace
which implies the schema should specify qualified elements. Preference- leave
schema alone, not use a defaulat namespace in example, prefix the ebXMLHeader
element with say "hdr." and add a namespace definition for
"hdr' on the ebXMLHeader element. |
email
dated 10/1 |
|
| Appendix
B.1 |
Mike Leditschke |
Should ebXML be providing a URL
for its schemas to which instance documents can be pointed via a
schemaLocation attribute? |
email
dated 10/1 |
|
| use of
version attribute |
Mike Leditschke |
Concerns over the use of a
version attribute for providing "future versioning capabilities".
The XML schema spec talk only of parsers using namespaces and schemaLocation
attributes as a means of locating the appropriate schema--no mention of version
attribute nor the semantics attached to them. COMMENT |
email
dated 10/1 |
|
| 182,
212-215, 220, 244-247, 304-306 |
Warren Buckley |
Make content-length
optional. In a nutshell, the
requirement to include Content-Length in the Message, Header and Payload
Envelopes means that any sender must 1) calculate the lengths and 2) have
enough buffer space to hold the content before sending. I believe this will
have an adverse effect when it comes to implementing processes that create,
route and receive ebXML messages. |
email dated 10/5 |
|
| Line 172 |
Henry Lowe |
modify text toread "XML or
other document(s) for the ebXML Payload" |
email dated 10/6 |
|
| Lines
185-195 |
Henry Lowe |
Replace "For example"
with "It must be" |
email dated 10/6 |
|
| Lines
221 - 278 |
Henry Lowe |
Text does not completely match
figure 2.1 The finugre does not have a label on the 'Container'. In fact, the
light and dark gray shaded boxes are the container and should be labeled in
the figure. |
email dated 10/6 |
|
| Lines
267-269 |
Henry Lowe |
In the example, Context-Type
does not have ites attributes version and charset specified. The text of section 2.3.3 says they MUST
be present. |
email dated 10/6 |
|
| Lines
283-284 |
Henry Lowe |
The Payload Container can carry
more than one document by having
appropriate references in the Manifest.
It would be useful if something to this effect were added to this section,
probably in this paragraph. Suggested
text: "The Payload Container may contain more than one document and the
Message Manifest provides references which allow documents to be
distinguished." |
email dated 10/6 |
|
| Line
297 |
Henry Lowe |
The text "This is the
implementor's decision" implies it is entirely up to the
implementor as to whether (s)he wants to carry multiple documents and
how it is done. This isn't quite the case as the Document
Reference, section 3.2.1, is the standardized method for distinguishing
multiple documents. A statement to this effect and
reference to 3.2.1 should be added. It might, also, be nice to add
another example in 3.2.1 illustrating the case for multiple documents in
the same payload container. |
email dated 10/6 |
|
| Line 326 |
Henry Lowe |
It is not clear what this
means. Explanation should be added. |
email dated 10/6 |
|
| Line
403-416 |
Henry Lowe |
I thought we had agreed that
PartyID would be a URI. This section should be updated
accordingly. |
email dated 10/6 |
|
| Line
412-414 |
Bernd Eckenfels |
I would allow the PartyID
Element to occur multiple times, so you can give all the known contexts.
This will enable us to se a DUNS Number, a ILN Number, a TAX Code a
Company Name, a e-mail Address, a van mailbox id and so on. This is especially
good for routing. |
email from David Burdett dated
10/9 |
|
| Line
451-453 |
Bernd Eckenfels |
if there is no earlier message
we should require the element to be not present, not to be empty. Or if
we want to have it empty but present, then we should tell this
explicitely: if there was no former message the ELEMENT has to be
present and be empty </ RefToMessageID>
or <RefToMessageID></RefToMEssageID>. Personally I think we
should require the element to be skiped if it is empty. We should also
define what kind of message we are referencing to: a order change can
reference to the order send or it can reference to the
order-dis-acknowledgement of the partner. PErhaps we should allow the
RefToMessageID to be repeatable and add an additional Attribute: context= |
email from David Burdett dated
10/9 |
|
| Line 460 |
Bernd Eckenfels |
we should state who will
interpret the ReliableMesssageInfo field and what he should do with it.
In the enumeration we should also add the "AtLeastOnce" or
something like this. Cause this is the normal way transmission protocols
without duplicate checking will work (SMTP for example). Filtering
duplicates should be responsebility of the endpoints. |
email from David Burdett dated
10/9 |
|
| Line
551-591 |
Bernd Eckenfels |
i would allow the following
elements to be optional: (the > reason for this is it is better to allow
them to be removed than everybody is making something "up" to
fill in them. TPAInfo, ReliableMessageInfo, ServiceInterface , Action,
ConversationID, make RefToMessageID (0-n)=* |
email from David Burdett dated
10/9 |
|
| Appendix
B.1 |
John Neve |
The example does not implemtn
the proposed structure |
email dated 10/10 |
|
| Line 634 |
John Neve |
Why not allow multiple receivers |
email dated 10/10 |
|
| Sect
2.2.1 |
John Neve |
Are we sure there is a business
justification in AtMostOnce value? |
email dated 10/10 |
|
| Sect
2.2.2 |
John Neve |
Shouldn't there be a value with
meaning 'at least 1, and if more, other occurrences must bear a Possible
Duplicate Flag with reference to previous attempts? |
email dated 10/10 |
|
| Line 663 |
John Neve |
There should be more that 1
RefToMessageID |
email dated 10/10 |
|
| Sect
2.4.1 |
John Neve |
BusinessServiceInterface -
multiple occurrences should be allowed |
email dated 10/10 |
|
| Sect 2.5 |
John Neve |
Action Multiple occurrences of
ServiceInterface should be allowed |
email dated 10/10 |
|
| Sect
3.1.1 |
John Neve |
A TestLiveMode flag with value
Test or Live should be added |
email dated 10/10 |
|
| Sect
3.1.2 |
John Neve |
see comments for list of
proposed additions to spec. |
email dated 10/10 |
|
| Sect
7.2.1 |
Gait Boxman |
clarification
regarding the use of charset attribute. Submitter believes we have used it in
error. |
email dated 10/10 |
|
|
|
|
|
|
|