Re: some data typing issues in 0.91

[Christopher Ferris <chris.ferris@east.sun.com>]

Andrew,

Thanks for the careful analysis! Unfortunately, because we've finished
the all the edits for v0.92, these proposed changes will have to be addressed
in the next version. We can add consideration of these comments to
the agenda on Thursday when we can vote on the changes.

Some additional comments below.

Cheers,

Chris

Andrew Eisenberg wrote:
> 
> During our last teleconference I said that I would look at some data typing
> issues in the spec.
> 
> I'd like to suggest the following changes:
> 
> 1) 8.4.6.2 Timestamp element, page 25, lines 555-558
> 
>    I believe the answer to DB's question is YES.
> 
>    Proposal: Replace these lines with the following:
> 
>       The Timestamp is a value representing the time that the
>       message header was created. A value for this element must
>       be an instance of an XML Schema timeInstant.
> 
> 2) 8.4.7.4 TimeToLive attribute, page 27, lines 633-634
> 
>    Align the wording here with the previous change, avoiding mention of
>    ISO 8601.

Given the last note in this email, that timeInstant conforms to ISO8601,
why should we avoid mention of ISO 8601? I think that we could at least
mention this, possibly with a direct reference/quote from the XMLSchema
spec.

Thoughts?

> 
>    Proposal: Replace this paragraph with the following:
> 
>       TimeToLive is an optional attribute that indicates the time by
>       which a message should be delivered to the To PartyMessage
>       Service Handler. A value for this element must be an instance
>       of an XML Schema timeInstant.
> 
> 3) 10.6.4.3 Timeout Parameter, page 52, lines 1548-1550
> 
>    This parameter specifies an integer number of seconds. This can
>    be more directly represented by an XML Schema timeDuration. 10
>    seconds would be represented with the value "PT10S".
> 
>    Proposal: Replace this paragraph with the following:
> 
>       The timeout parameter specifies the time in seconds that the
>       Sending MSH MUST wait for an Acknowledgement Message before
>       first resending a message to the Receiving MSH.
> 
>       <AE>The definition of this parameter seems to be missing from
>       Appendix A.1 Schema Definition. When it is added, it should
>       appear as follows:
> 
>          <xsd:element name="timeout">
>             <xsd:simpleType>
>                <xsd:restriction base="xsd:timeDuration"
>                   <xsd:pattern value="PT\d+S" />
>                </xsd:restriction>
>             </xsd:simpleType>
>          </xsd:element>
>       </AE>
> 
> 4) 10.6.4.5 RetryInterval Parameter, page 52, lines 1556-1557
> 
>    Make the same change that was made for the timeout parameter.
> 
>    Proposal: Replace this paragraph with the following:
> 
>       The retryInterval parameter specifies the time in seconds that the
>       Sending MSH MUST wait between retries, if an Acknowledgement
>       Message is not received.
> 
>       <AE>The definition of this parameter seems to be missing from
>       Appendix A.1 Schema Definition. It should have a definition
>       similar to that of the timeout parameter when it is added.</AE>
> 
> 5) 10.6.5.2 PersistDuration, page 52, lines 1581-1590
> 
>    Proposal: Add the following text to the end of the section:
> 
>       <AE>The definition of this parameter seems to be missing from
>       Appendix A.1 Schema Definition. When it is added, it should
>       appear as follows:
> 
>          <xsd:element name="PersistDuration">
>             <xsd:simpleType>
>                <xsd:restriction base="xsd:timeDuration">
>                   <xsd:pattern value="P\d+D" />
>                </xsd:restriction>
>             </xsd:simpleType>
>          </xsd:element>
>       </AE>
> 
> 6) 10.6.5.3 MSH Time Accuracy, page 53, lines 1592-1594
> 
>    Proposal: Add the following text to the end of the section:
> 
>       <AE>The definition of this parameter seems to be missing from
>       Appendix A.1 Schema Definition. When it is added, it should
>       appear as follows:
> 
>          <xsd:element name="mshTimeAccuracy">
>             <xsd:simpleType>
>                <xsd:restriction base="xsd:timeDuration"
>                   <xsd:pattern value="PT((\d+M)|(\d+S)|(\d+M\d+S))" />
>                </xsd:restriction>
>             </xsd:simpleType>
>          </xsd:element>
>       </AE>
> 
> 7) Appendix A.1 Schema Definition, page 70, line 2171
> 
>    The syncReplyMode attribute described in 8.4.7.3 is missing from
>    the schema definition.
> 
>    Proposal: After line 2171 add the following:
> 
>       <xsd:attribute name="syncReplyMode" type="xsd:boolean"/>
> 
> 8) Appendix A.1 Schema Definition, page 72, line 2328
> 
>    "<!-- Does timeInstant conform to ISO 2601? -->
> 
>    I believe ISO 8601 was the intended reference, and the answer is YES.
> 
>    XML Schema Part 2: Datatypes states in 3.3.24.1 Lexical Representation:
> 
>       "A single lexical representation, which is a subset of
>       the lexical representations allowed by [ISO 8601], and is the
>       same lexical representation as its basetype recurringDuration
>       is allowed for timeInstant."
> 
>    Proposal: Drop this line.

Do you mean "drop the comment line" from the xsd?

> 
> I hope that you all had a productive meeting in London.

I believe that we did. We didn't get to cover all that we had planned,
but it was productive and we did make some significant progress.

> 
>                                                         -- Andrew
> 
> --------------------------------------------------------------------------------
> Andrew Eisenberg                                   andrew.eisenberg@progress.com
> Progress Software Corp.
> 14 Oak Park                                        phone: 781-280-4526
> Bedford, MA  01730                                 fax:   781-280-4949
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;One Network Drive;Burlington;Ma;01803-0903;USA
version:2.1
email;internet:chris.ferris@east.sun.com
title:Senior Staff Engineer
fn:Christopher Ferris
end:vcard