[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Connected again: Here's the rest of my comments on 0.21d
Regarding Doug's comment on persistent storage, sect. 7.11, lines 754 and
771:
For the sending message service handler, it should be possible to define
the point at which a message can be deleted from persistent storage. For
the receiving side, it is much less clear when the message can be removed
from persistent storage since the received message must be able to be
guaranteed to reach the application and be processed. Defining the
endpoint probably oversteps the boundaries of the messsage service handler
and potentially gets into architecting the implementation. Defining the
endpoint would make assumptions on how the implementation guarantees that
the message actually reaches the application. I believe that we discussed
this issue when the original reliable messaging proposal was discussed and
decide that it would be best to simply leave the message's life in
persistent storage open-ended.
Regards,
Marty
*************************************************************************************
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
*************************************************************************************
Doug Bunting <Doug@ariba.com> on 11/07/2000 11:44:21 AM
To: "Christopher Ferris (E-mail)" <chris.ferris@east.sun.com>, "Martha
Warfelt (E-mail)" <maw2@daimlerchrysler.com>, "'ian.c.jones@bt.com'"
<ian.c.jones@bt.com>
cc: "'ebXML Transport'" <ebxml-transport@lists.ebxml.org>
Subject: Connected again: Here's the rest of my comments on 0.21d
Deep breath, here we go with the rest of my comments (including DTD and
schema recommendations):
Sections 7.9.1, 7.9.2.1 and 7.9.2.2, lines 615-617 and 633-638:
These values (PartyId, TPAId and ConversationId) appear to be strings
meaningful in a particular context. Without the optional context
attribute, they must take the form of a uriReference. When a context
attribute is provided, they may take any value valid in that context
(whether or not that's a valid uriReference). Add words describing these
identifiers as strings. Add words describing the semantics of the context
attribute (just improve the wording for lines 615-617).
Section 7.9.3.3, lines 669-671:
Error messages may be sent in response to Normal messages in which no
MessageId could be found. There is an earlier message, but its MessageId
is unknown. This case should be described in this paragraph. An
additional sentence such as "For Error messages, the RefToMessageId
reference is mandatory and its value MUST be the MessageId of the message
in error (as defined in section 7.13.1) unless that MessageId cannot be
determined." Hopefully, we're not trying to support Error messages
containing errors found in multiple original (Normal) messages.
Section 7.10, lines 713-715:
SenderURI, ReceiverURI and ErrorURI are not defined. Are they
identifiers or service locations? From later discussion in this document,
it appears that ErrorURI is a service location at which error responses
may be received. The other two aren't discussed much. However, I'd
recommend they be defined similarly to the PartyId elements in the Header
(ie. the parties participating in the current leg of the journey). That
requires adding a context attribute to SenderURI and ReceiverURI and
(potentially) renaming the elements. Alternatively, SenderURI and
ReceiverURI may somehow identify the service location used in this
particular leg (this is probably redundant information for ReceiverURI with
the transport destination and SenderURI may not exist -- not all senders
are reachable in return).
Section 7.10, lines 719-730:
SequenceNumber as defined adds little or no value over the MessageID
element required in MessageData. Recommend removing this section and the
corresponding references to SequenceNumber in later examples, the DTD and
the schema.
Section 7.10, line 727:
If this section remains, must define the exact content of the
SequenceNumber element when the numeric value is greater than 999. Is the
next value "1000" or "1,000"? Is the text for the maximum value
"999999999" or "999,999,999" or are both allowed (and equivalent)? Side
note: Numeric formats vary by locale and a comma is not always the
thousands separator. Further, "Punctuation as in US English." (to quote
the "Specific Datatypes" section of the
http://www.w3.org/TR/1998/NOTE-XML-data-0105/ document) doesn't answer my
questions above.
Section 7.10, line 730:
If this section remains, "long time" should be defined. At least, refer
to a TPA which makes this concrete for a specific trading relationship or
mention later text on this subject (if any).
Section 7.11, lines 754 and 771 (at least):
"Persistent storage" actually lasts how long? Is the original message
deleted by the Messaging Service immediately after receiving an
acknowledgement? In the case of an error which is reported to the sending
application (party), does that report also result in deletion of the
original message from the persistent storage?
Section 7.11, lines 784-787:
What information does the Receiver store persistently in this step?
Recommend storing the MessageID of the original message and the entire
response document. To check for "exactly the same as the original
message" as described on line 828, may be necessary to store entire
original message or its checksum as well.
Section 7.11, line 798 (editorial):
Add word "Service" to "Sender's Messaging", completing the sentence.
Section 7.12, line 817:
The Timeout and RetryInterval parameters have different semantics as
described later in this document. However, that difference is not made
clear in this table. Recommend RetryInterval definition be changed to
"Wait time between receiving notification of a transport error and sending
a retry.
* Integer value specifying number of seconds.
* After any error response is received, the Sender SHALL wait for the
specified time before sending a retry document." If the intended
semantics of RetryInterval require that documents not be send more often
than the specified interval (requiring the Sender to wait for a timeout,
declaring that status and then beginning a wait for RetryInterval), that
could be described by changing my words above to include a bullet such as
"* Notification of a transport error includes detecting an expired timeout
while awaiting a response."
Section 7.13.4, lines 892-907:
The wording of this section explicitly prevents leaving out the ErrorURI
and relying on the immediate response available in some transports. For
example, sending a message via HTTP may not require the ErrorURI because
the receiver always completes MS handling in "real time" and returns an
Error document (if necessary) in the immediate HTTP response. Recommend
this case be supported by including words to this effect rather than
leaving it "outside the scope of this document".
Section 7.13.5.3.4, lines 948-951:
Either the Description element should be allowed to repeat (providing
multiple descriptions of the error in various locales) or a Normal message
should specify the preferred locale for Error messages. Without this, the
Description content is not going to be useful with multiple,
interoperating systems.
Section 7.13.5.5.2, lines 1004-1006:
How does this RefToMessageId relate to the one in MessageData? Since we
aren't attempting to handle an Error response covering multiple messages
in error (right?), change the last sentence to be "This must be present
[and have the same value as the RefToMessageId in the MessageData element
of the Header] if a MessageId can be identified in the message in error."
Section 7.13.5.7, lines 1024-1043:
Either the DTDs and schemas are normative or not. It doesn't make sense
to handle the DTD for ebXMLError differently from the DTD and schema for
ebXMLHeader. Move this section to a (new) appendix A.3. By the way,
appendix A should be normative though it isn't necessary for it to
interrupt the regular flow of the text.
Section 7.13.5.7, line 1027:
This is likely a duplicate. Just wanted to make sure we noted that
"<schema ...>" either shouldn't appear in the DTD or must be a processing
instruction ("<?schema ...?>").
Section 7.13.5.7, line 1028:
According to the text of section 7.13.5.5, we've got a meaning for a
minimum of one ErrorLocation element. Either change "ErrorLocation*" to
"ErrorLocation+" (requiring one or more such element) or define the
meaning of zero ErrorLocation elements in section 7.13.5.5. For the
second resolution, add "If no ErrorLocation element is provided, no
information about the specific location of the error is available. When a
MessageId can be determined from the message in error, the ebXMLError must
contain one or more ErrorLocation elements." to the end of section
7.13.5.5.
Section 7.13.5.7, line 1029:
According to the text of section 7.13.5.3.5, the SoftwareDetails element
is optional. Change "SoftwareDetails" to "SoftwareDetails?".
Section 7.13.5.8, lines 1049-1052:
Are the two "narrative" types of information contained in the Description
element or the ErrorCode? Replace "that immediately follows the error
code" with "beginning the Description element" on line 1049. And, replace
"that follow the narrative" with "that follow the narrative (completing
the Description)" on line 1051.
Section 8.1, lines 1118-1120:
The Internet Draft on XML Media Types is now an RFC. RFC 2376 (XML Media
Types) has been available since July 1998. That document must be
normative for this specification. Update the reference in these lines.
Section A.1, lines 1238-1287:
The DTD uses Extensibility mechanisms for including datatype information.
Either here or in section 8.2, add a non-normative reference to some
description of these mechanisms.
Section A.1, line 1239:
This is likely a duplicate. Just wanted to make sure we noted that
"<schema ...>" either shouldn't appear in the DTD or must be a processing
instruction ("<?schema ...?>").
Section A.1, lines 1242-1243:
To validate any of the given examples, need definition of the xmlns
pseudo-attribute (it's an attribute as far as a parser with no knowledge
of namespaces is concerned). Add 'xmlns CDATA #FIXED "
http://www.ebxml.org/namespaces/messageHeader"'to the ATTLIST. Note:
There's no way to require an attribute with this value in every instance
document in a DTD. A #FIXED attribute is (unfortunately) optional in a
particular document.
Section A.1, line 1241:
The RoutingHeader element should be optionally allowed in the ebXMLHeader
element. Add ", RoutingHeader?" after Header in this content model.
Section A.1, line 1243:
This definition of the MessageType attribute prevents any values except
"Normal" and makes it optional in a document. In addition, the text of
section 7.7.1.3 says this attribute is an enumeration. Change this line
to read "MessageType (Normal | Acknowledgment | Error) #REQUIRED".
Section A.1, line 1244:
Requiring one or more DocumentReference elements in a Manifest disallows
a message of type "Acknowledgment". We need to support an empty Manifest.
In addition, the DTD and schema disagree on this point (the schema appears
to be correct). Change the "+" at the end of this line in the DTD to "*".
Section A.1, line 1245:
This line is invalid in a DTD. Remove the space in "Document
Description".
Section A.1, lines 1251, 1260, 1263, 1273, 1279, 1281 and 1283:
Depending upon the resolution of my previous comments on the PartyId,
TPAId, ConversationId, SenderURI and ReceiverId, their datatypes should
change to 'string' and a few might be renamed and / or they could gain a
context attribute. Regardless of those changes, the "uri" datatype
doesn't exist in the W3C Schema proposal. The closest type is
"uriReference" and we should either use W3C Schema datatypes consistently
or describe their equivalents in the DTD (for the elements which continue
to have this type, which might be only DocumentId, PartyId and Href).
Section A.1, lines 1259, 1262 and 1272:
The context attribute has no defined default value according to the text
of the one element (PartyId) which mentions it. Use of a default such as
"Undefined" for the TPAId, ConversationId and PartyId element's context
attribute adds no value over leaving the attribute out completely. It
also changes the "experience" of a receiving application depending upon
the configuration of the underlying XML parser. Change 'Undefined' to
#IMPLIED on each of these lines.
Section A.1, line 1264:
The RefToMessageId element is optional in this context (as it is in
ErrorLocation) according to the text of section 7.9.3.3. Add a "?" after
this element in the MessageData element.
Section A.1, lines 1264 and 1268:
The "uuid" datatype doesn't exist in the W3C Schema proposal. Further,
this datatype in the XML Data proposal (which Extensibility referenced as
normative) requires a particular format for the unique identifier (128
bits expressed in hexadecimal format). As long as these values are
globally unique, we should not restrict implementations that much. For
example, a value created according to the rules for a MIME content
identifier would be fine. Change the datatype of these values to be
"string".
Section A.1, line 1275:
This definition of the DeliverySemantics attribute in
ReliableMessagingInfo prevents any values except "BestEffort" and makes it
optional in a document. Change this line to read "... #REQUIRED" instead
of '... #FIXED "BestEffort"'.
Section A.1, line 1277:
The SequenceNumber element is optional according to section 7.10. Add a
"?" after this element in the content model.
Section A.2, lines 1294-1295:
The RoutingHeader element should be optionally allowed in the ebXMLHeader
element. Add '<element ref="RoutingHeader">' after the Header line in
this sequence. Also, define the content of that element (to match the
definition in the DTD) later in the schema.
Section A.2, line 1298:
This definition of the MessageType attribute prevents any values except
"Normal" and makes it optional in a document. In addition, the text of
section 7.7.1.3 says this attribute is an enumeration. Change this line
to read
<attribute name="MessageType" use="required">
<simpleType base="ENUMERATION">
<enumeration value="Normal">
<enumeration value="Acknowledgment">
<enumeration value="Error">
</simpleType>
</attribute>
Section A.2, line 1310:
This sequence should not have minOccurs or maxOccurs constraints since it
is a simple sequence of the contained elements. The element containing
DocumentReference (Manifest) already allows it to repeat as described in
the text. Remove these constraints.
Section A.2, line 1311:
According to the text in section 7.8.1.1 and the DTD, the
DocumentDescription is optional. Add a 'minOccurs="0"' constraint to this
element reference.
Section A.2, line 1311:
In addition to the above point, the DocumentDescription element is not
defined in the schema. After line 1316, add
<element name="DocumentDescription">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="xml:lang" type="language" />
</extension
</simpleContent>
</complexType>
</element>
This might not be correct in the W3C schema language: It's my best guess.
Section A.2, lines 1336, 1341 and 1375:
base is not a valid attribute for the complexType element and textOnly is
not a valid value for the content attribute. This probably requires
something similar to the previous suggestion.
Section A.2, lines 1336, 1341 and 1375:
Depending upon the resolution of my previous comments on the PartyId,
TPAId, ConversationId, SenderURI and ReceiverId, their datatypes should
change to 'string' and a few might be renamed and / or they could gain a
context attribute. Regardless of those changes, the "uri" datatype doesn't
exist in the W3C Schema proposal. The closest type is "uriReference" (for
the elements which continue to have this type, which might be only
DocumentId, PartyId and Href).
Section A.2, lines 1337, 1342 and 1376:
The context attribute has no defined default value according to the text
of the one element PartyId which mentions it. Use of a default such as
"Undefined" for the TPAId, ConversationId and PartyId element's context
attribute adds no value over leaving the attribute out completely. It
also changes the "experience" of a receiving application depending upon
the configuration of the underlying XML parser. Remove 'use="default"
value="Undefined"' on each of these lines.
Section A.2, line 1354:
The RefToMessageId element is optional in this context (as it is in
ErrorLocation) according to the text of section 7.9.3.3. Add 'minOccurs
="0"' to this element in the MessageData's content.
Section A.2, lines 1354 and 1358:
The "uuid" datatype doesn't exist in the W3C Schema proposal. Further,
this datatype in the XML Data proposal (which Extensibility referenced as
normative) requires a particular format for the unique identifier (128
bits expressed in hexadecimal format). As long as these values are
globally unique, we should not restrict implementations that much. For
example, a value created according to the rules for a MIME content
identifier would be fine. Change the datatype of these values to be
"string".
Section A.2, lines 1381:
This definition of the DeliverySemantics attribute in
ReliableMessagingInfo prevents any values except "Unspecified" (which isn't
valid in according to the enumeration) and makes it optional in a
document. Change line to read 'use="required"' instead of 'use="fixed"
value="Unspecified"'.
Section B.1, line 1408:
version must have value '1.0' to be valid.
Section B.1, line 1417:
The text of this specification does not make it clear how the DTD should
be referenced in an instance document. A relative URI implies that all
parties have already cached the DTD. Recommend a fully qualified location
on the Internet (using the http scheme) for these files.
Section B.1, line 1445:
The RefToMessageId element should be optional. Leave it out of the
example rather than using an undefined "placeholder" value such as 'Not
Applicable'.
Section B.1, lines 1450 and 1456:
The specification does not define a RouteInfo element. Remove this layer
from the example.
Section B.1, lines 1451-1452:
The SenderURI and ReceiverURI values are not valid URI references. Add
https:// to the content of both elements.
Section B.2, line 1539:
This example should be consistent. Use the actual content identifier of
the payload (ebxmlpayload-9000).
Section B.2, line 1565:
The RefToMessageId element should be optional. Leave it out of the
example rather than using an undefined "placeholder" value such as 'Not
Applicable'.
Section B.2, line 1567:
A value of Unspecified is not legal in the enumeration for the
DeliverSemantics attribute. Use either BestEffort or OnceAndOnlyOnce.
Section B.2, lines 1573 and 1588:
Provide some reason to believe there may be 7515 octets in this part or
reduce the Content-length.
Section D, lines 1664-1667:
Why would browser vendors directly implement any semantics defined by
multipart/related (even) or ebXML? The application-level requirements of
ebXML don't lend themselves to a display interface. Business code
downloaded to operate in the context in a browser (Active X or Java,
whatever) may implement all of ebXML without additional work done by the
browser itself. Remove this paragraph.
Section E.1, lines 1672-1680:
This binding to HTTP explicitly prevents optimizations using the
immediate HTTP responds to carry an acknowledgement, error or business
response. It also prevents ebXML implementation using an HTTP client
without an associated HTTP server available directly from the Internet
(not hidden behind a firewall). Delete this section and revisit all of
the contained materials while implementing later phases of this project.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC