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] issues list

All,

As mentioned on the call, I have tweaked the W3C XML Protocol WG
issues list for our needs, and have established as a baseline the
issues I raised with my vote on 2.0.

Attached are the XML, XSLT, DTD and HTML, all of which should be
posted to our website. We need to be sure that the DTD retains the
W3C IP disclaimer.

Comments welcomed. I'll gladly make any necessary changes
to the schema or styling.

Cheers,

Chris
Title: OASIS ebXML Message Service TC Issues List
OASISOASIS ebXML Messaging TC

OASIS ebXML Messaging TC Issues List

Last update: January 30, 2002

Issues regarding the documents produced by the OASIS ebXML Messaging TC should be reported to ebxml-msg@lists.oasis-open.org (public archives).

Comments on this list should be sent to the ebxml-msg@lists.oasis-open.org mailing list (Archives).

Summary List of Outstanding Issues

id Status Spec Topic Class Section Title
1 Active line 15/16 spec editorial title page title page
2 Active line 17/18 spec editorial title page boilerplate
3 Active line 20 spec editorial title page title page
4 Active line 23 spec editorial ebXML participants ebXML participants
5 Active line 26 spec editorial ebXML participants ebXML Participants
6 Active line 200 spec editorial Introduction typo
7 Active line 208 spec editorial Introduction typo
8 Active line 214 spec editorial Introduction editorial tweak
9 Active line 472 spec editorial 2.1 Packaging Specification editorial tweak
10 Active line 509 spec editorial 2.1.2 Message Package RFC2119 usage
12 Active line 724 spec editorial 2.3.10 NextMSH actor URI editorial tweak
13 Active line 732 spec editorial 2.3.11 ToPartyMSH actor URI editorial tweak
14 Active line 764 spec editorial 3.1.1 From and To Party elements RFC2119 usage/typo
15 Active line 784 spec editorial 3.1.1.2 PartyId element RFC2119 usage
16 Active line 788 spec editorial 3.1.1.2 Role element replacement text for Note
17 Active line 810 spec editorial 3.1.2 CPAId element CPA
18 Active line 831 spec editorial 3.1.3 ConversationId element typo
19 Active line 872 spec editorial 3.1.6.1 MessageId element local part of MID?
20 Active line 899 spec editorial 3.1.7 DuplicateElimination element duplicate detection
22 Active line 903 spec editorial 3.1.8 DuplicateElimination element "if there is a CPA with ..." is a little too vague
23 Active line 914 spec editorial 3.1.9 MessageHeader example example issue
24 Active line 942 spec editorial 3.2 Manifest element premature reference to xlink:role
27 Active line 1029 spec editorial 4.1.2.1 Collaboration Protocol Agreement RFC2119 usage
28 Active line 1037 spec editorial 4.1.3 Signature Generation typo
29 Active line 1050 spec editorial 4.1.3 Signature Generation editorial tweak
31 Active line 1436 spec editorial 7 Reliable Messaging Module duplicate eleimination characterization
33 Active line 1459 spec editorial 7.2 Methods ... editorial tweak
35 Active line 1564 spec editorial 7.3.2.5 [XMLDSIG] Reference typo
38 Active line 2054... spec editorial 11 Multihop... duplicate content with 11.1.4
39 Active line 2791... spec editorial Non-Normative References references to ebXML specs
26 Active line 982 spec minor technical 3.2.2 Manifest validation suggestion to discard note
11 Active line 709 spec technical 2.3.8 version attribute confusion w/r/t conformance
21 Active line 901 spec technical 3.1.8 DuplicateElimination element duplicate elimination confusion
25 Active line 972, 1321 spec technical 3.2.1.2 Description element Description element
30 Active line 1434 spec technical 7 Reliable Messaging Module RFC2119 MUST semantics for DFN
32 Active line 1449 spec technical 7.1 Persistent Storage... RFC2119 usage
34 Active line 1512 spec technical 7.3.1.4 AckRequested error on ack and ack on error issue
36 Active line 1580 spec technical 7.3.2.8 Acknowledgment... error on ack
37 Active line 1809 spec technical 8.1.2 MessageStatus... incorrect URI
40 Active line 2245(95) schema editorial Appendix A restore comment in schema
45 Active line 2374(???) schema editorial Appendix A headerExtension.grp attribute group should be derived by extension from the bodyExtension.grp
46 Active line 2397(240) & 2403(248) schema editorial Appendix A Role element is used twice but not defined in a common location
44 Active line 2282(126) schema major technical Appendix A sequenceNumber.type is poorly defined
41 Active line 2281(125) schema technical Appendix A Acknowledgment/RefToMessageId element should be removed
42 Active line 2282(126) schema technical Appendix A Acknowledgment/From element is not particularly useful
43 Active line 2304(148) schema technical Appendix A Description element here doesn't match the document
47 Active none schema technical Appendix A Schema element should have an optional "namespace" attribute
48 Active line 2169(???) schema technical Appendix A Import correct / latest schema for XML namespace

Detailed List of Issues

id Spec Section Topic Class Status Raised By Owner
1 line 15/16 title page spec editorial Active Chris Ferris
Title: title page
Description: [see email]the date cited here should be consistent with its adoption as a TC, not the date that the document was published to the TC for consideration (vote). Given that the ballot is closed as of January 18, then the date cited here cannot be less than that date.
Proposal:
Resolution: none
2 line 17/18 title page spec editorial Active Chris Ferris
Title: boilerplate
Description: [see email] either the tense is incorrect (is presented) or this should be removed. Suggest that the latter be applied. In the event that the OASIS membership does approve the TC specification as an OASIS Standard, then I could see adding something to that effect.
Proposal: make suggested change
Resolution: none
3 line 20 title page spec editorial Active Chris Ferris
Title: title page
Description: [see email] need to update the URI reference here. Should follow w3c approach and have a stable URI that people can reference which will always have the latest draft, in addition to an explicit URI for the specific reference to a specific draft for use in external references, etc.
Proposal: make suggested change
Resolution: none
4 line 23 ebXML participants spec editorial Active Chris Ferris
Title: ebXML participants
Description: [see email] I agree that having this section (ebXML Participants) in addition to the one in the appendix is both gratuitous and confusing. Suggest that we have but a single list, and that that list be in an appendix, if anywhere. There is no reason to cite the participants of the original ebXML project team.
Proposal: remove section "ebXML Participants"
Resolution: none
5 line 26 ebXML participants spec editorial Active Chris Ferris
Title: ebXML Participants
Description: [see email] If the section is preserved (see issue 4), then s/meeting/meetings/
Proposal: make suggested change
Resolution: none
6 line 200 Introduction spec editorial Active Chris Ferris
Title: typo
Description: [see email] s/sending and receiving/that sends and receives/
Proposal: make suggested change
Resolution: none
7 line 208 Introduction spec editorial Active Chris Ferris
Title: typo
Description: [see email] s/,//
Proposal: make suggested change
Resolution: none
8 line 214 Introduction spec editorial Active Chris Ferris
Title: editorial tweak
Description: [see email] s/Elements/Features/
Proposal: make suggested change
Resolution: none
9 line 472 2.1 Packaging Specification spec editorial Active Chris Ferris
Title: editorial tweak
Description: [see email] s/the following figure/figure 2.1/
Proposal: make suggested change
Resolution: none
10 line 509 2.1.2 Message Package spec editorial Active Chris Ferris
Title: RFC2119 usage
Description: [see email] s/may/can/
Proposal: make suggested change
Resolution: none
11 line 709 2.3.8 version attribute spec technical Active Chris Ferris
Title: confusion w/r/t conformance
Description: [see email] this is going to lead to all manner of confusion. For conformance to THIS specification, all of the version attributes on any SOAP extension elements defined in THIS specification MUST have a value of "2.0". An ebXML message MAY contain SOAP header extension elements that have a value other than "2.0". An implementation conforming to this specification that receives a message with ebXML SOAP extensions qualified with a version other than "2.0" MAY process the message if it recognizes the version identified and is capable of processing it. It MUST respond with an error (details TBD) if it does not recognize the identified version.
Proposal: make suggested change
Resolution: none
12 line 724 2.3.10 NextMSH actor URI spec editorial Active Chris Ferris
Title: editorial tweak
Description: [see email] s/The /The URI /
Proposal: make suggested change
Resolution: none
13 line 732 2.3.11 ToPartyMSH actor URI spec editorial Active Chris Ferris
Title: editorial tweak
Description: [see email] s/The /The URI /
Proposal: make suggested change
Resolution: none
14 line 764 3.1.1 From and To Party elements spec editorial Active Chris Ferris
Title: RFC2119 usage/typo
Description: [see email] s/must/MUST/
Proposal: make suggested change
Resolution: none
15 line 784 3.1.1.2 PartyId element spec editorial Active Chris Ferris
Title: RFC2119 usage
Description: [see email] use of the term OPTIONAL here may be confusing given the conformance statement. Suggest that this be rephrased as follows: The Role element, if present, ... (technical/editorial) Other instances of OPTIONAL where ordinality is meant: * 500 (MIME start parameter) * 1801, 1814 (Signature element in Message Status Request & Response) * 1822, 1842 (StatusRequest and StatusResponse elements; really, the service is OPTIONAL) * 1905, 1955 (Signature element in Ping & Pong)
Proposal: make suggested change
Resolution: none
16 line 788 3.1.1.2 Role element spec editorial Active Chris Ferris
Title: replacement text for Note
Description: [see email] suggested replacement text for the Note: Note: Use of a URI for the value of the Role element is RECOMMENDED. e.g. http://rosettanet.org/roles/buyer
Proposal: make suggested change
Resolution: none
17 line 810 3.1.2 CPAId element spec editorial Active Chris Ferris
Title: CPA
Description: [see email] given that we agreed in the f2f that there *was*/*is* a CPA, this sentence should be removed so as to avoid any unnecessary confusion.
Proposal: make suggested change
Resolution: none
18 line 831 3.1.3 ConversationId element spec editorial Active Chris Ferris
Title: typo
Description: s/schema/scheme/
Proposal: make suggested change
Resolution: none
19 line 872 3.1.6.1 MessageId element spec editorial Active Chris Ferris
Title: local part of MID?
Description: [see email] We thought that an issue had been raised that challenged the "local part" characterization.
Proposal:
Resolution: none
20 line 899 3.1.7 DuplicateElimination element spec editorial Active Chris Ferris
Title: duplicate detection
Description: [see email] While it may be true that in order to ensure that duplicates are detected and prevented from being forwarded to the application, a persistent store is required, it is not a request by the sender that the receiver have a persistent store, it is a request by the sender that the receiver filter duplicate messages such that the application does not receive them. This section needs a better description.
Proposal:
Resolution: none
21 line 901 3.1.8 DuplicateElimination element spec technical Active Chris Ferris
Title: duplicate elimination confusion
Description: [see email] This too is going to be confusing to the reader. The semantics of duplicate elimination are such that the application that is to process the received message need not concern itself that it might be processing a duplicate message. The delivery semantics of this element alone might be either at-most-once or best-effort, but in conjunction with acknowledgments, retries, etc., can effect delivery semantics of once-and-only-once.
Proposal:
Resolution: none
22 line 903 3.1.8 DuplicateElimination element spec editorial Active Chris Ferris
Title: "if there is a CPA with ..." is a little too vague
Description: [see email] "if there is a CPA with ..." is a little too vague. This is related to the issue raised recently on the list[3]. We prefer that we be a bit more specific. Suggested text: The DuplicateElimination element MUST NOT be present if the DeliveryChannel for the message in the CPA identified by CPAId has a value of "never". The DuplicateElimination element MUST be present if the DeliveryChannel for the message in the CPA identified by CPAId has a value of "always".
Proposal: make suggested change
Resolution: none
23 line 914 3.1.9 MessageHeader example spec editorial Active Chris Ferris
Title: example issue
Description: [see email] (example) curious that the From party has no identified Role, but the To party does. Suggest that both be assigned a role or neither.
Proposal: make suggested change
Resolution: none
24 line 942 3.2 Manifest element spec editorial Active Chris Ferris
Title: premature reference to xlink:role
Description: [see email] this sentence seems premature since xlink:role is an attribute of Reference element which has not yet been defined. Suggest moving this sentence to the bullet defining xlink:role below (after line #961)
Proposal: make suggested change
Resolution: none
25 line 972, 1321 3.2.1.2 Description element spec technical Active Chris Ferris
Title: Description element
Description: [see email] The Description element defined in section 3.1.8 identifies the purpose of the Description element as describing the message. The Description element here is intended to provide for a description of the payload document identified by the Reference item. The structure/syntax of the element may be the same, but the purpose is quite different. Suggest that we reference the structure of the description element, but that we augment the definition here (and elsewhere throughout the spec) with the specific purpose of the element in the current context. In addition, the definition of the Description element at times conflicts with the schema (esp sect. 4.2.3.2.6). The Description element MUST not be empty as it extends non-empty-string.
Proposal: make suggested change
Resolution: none
26 line 982 3.2.2 Manifest validation spec minor technical Active Chris Ferris
Title: suggestion to discard note
Description: [see email] Chris previously sent a note suggesting that this Note be discarded. It isn't at all clear that it adds any value. Would add to text (or note) in section 3.2.2 that the xlink:href may be a Content-Location or a Content-ID as described in section 4.1.3, lines 1084-1089. If the ds:Reference element may have a URI of this type and that URI must match the xlink:href of some "corresponding" eb:Reference element, options must be similar.
Proposal: make suggested change
Resolution: none
27 line 1029 4.1.2.1 Collaboration Protocol Agreement spec editorial Active Chris Ferris
Title: RFC2119 usage
Description: [see email] s/may be/is/
Proposal: make suggested change
Resolution: none
28 line 1037 4.1.3 Signature Generation spec editorial Active Chris Ferris
Title: typo
Description: [see email] s/and //
Proposal: make suggested change
Resolution: none
29 line 1050 4.1.3 Signature Generation spec editorial Active Chris Ferris
Title: editorial tweak
Description: s/for the ebXML Message Service//
Proposal: make suggested change
Resolution: none
30 line 1434 7 Reliable Messaging Module spec technical Active Chris Ferris
Title: RFC2119 MUST semantics for DFN
Description: [see email] This was supposed to have been changed to MUST.
Proposal: make suggested change
Resolution: none
31 line 1436 7 Reliable Messaging Module spec editorial Active Chris Ferris
Title: duplicate eleimination characterization
Description: [see email] The method of duplicate elimination is not achieved via a persistent store, but is facilitated by same. The mechanism by which duplicates are detected and eliminated is via the MessageId. This is likely to become a source of confusion.
Proposal:
Resolution: none
32 line 1449 7.1 Persistent Storage... spec technical Active Chris Ferris
Title: RFC2119 usage
Description: [see email] s/SHOULD/MUST/
Proposal: make suggested change
Resolution: none
33 line 1459 7.2 Methods ... spec editorial Active Chris Ferris
Title: editorial tweak
Description: [see email] s/structures/extension modules/
Proposal: make suggested change
Resolution: none
34 line 1512 7.3.1.4 AckRequested spec technical Active Chris Ferris
Title: error on ack and ack on error issue
Description: [see email] We agreed that an error message could be sent reliably. You are only precluded from requesting an acknowledgment on a message that itself is an acknowledgment message.
Proposal: make suggested change
Resolution: none
35 line 1564 7.3.2.5 [XMLDSIG] Reference spec editorial Active Chris Ferris
Title: typo
Description: [see email] s/This/The/
Proposal: make suggested change
Resolution: none
36 line 1580 7.3.2.8 Acknowledgment... spec technical Active Chris Ferris
Title: error on ack
Description: [see email] We did NOT agree to this at all. We agreed that an Error message *could* be sent reliably. Ref email for discussion.
Proposal: apply original TC resolution
Resolution: none
37 line 1809 8.1.2 MessageStatus... spec technical Active Chris Ferris
Title: incorrect URI
Description: [see email] URI s/b urn:oasis:names:tc:ebxml-msg:service
Proposal: make suggested change
Resolution: none
38 line 2054... 11 Multihop... spec editorial Active Chris Ferris
Title: duplicate content with 11.1.4
Description: [see email] this is essentially duplicate of the content of section 11.1.4, suggest it be deleted.
Proposal: make suggested change
Resolution: none
39 line 2791... Non-Normative References spec editorial Active Chris Ferris
Title: references to ebXML specs
Description: [see email] references to ebXML specs should be qualified by their URI, and as previously cited, the ebRS reference should probably cite the 2.0 version of their spec(s).
Proposal: make suggested change
Resolution: none
40 line 2245(95) Appendix A schema editorial Active Chris Ferris
Title: restore comment in schema
Description: [see email] Comment from last draft-msg-header-05.xsd had a useful annotation mentioning the soap:actor element in SyncReply MUST have the value http://schemas.xmlsoap.org/soap/actor/next Suggest restoring that inline documentation.
Proposal: restore comment
Resolution: none
41 line 2281(125) Appendix A schema technical Active Chris Ferris
Title: Acknowledgment/RefToMessageId element should be removed
Description: [see email] Doug raised an issue[1] that the Acknowledgment/RefToMessageId element should be removed. It remains in the document and the schema but should be removed. An Acknowledgment element should be included if and only if the overall message refers to the original one of interest.
Proposal:
Resolution: none
42 line 2282(126) Appendix A schema technical Active Chris Ferris
Title: Acknowledgment/From element is not particularly useful
Description: [see email] Doug believes he mentioned this before w.r.t. the document. The Acknowledgment/From element is not particularly useful because it provides the Receiving MSH no actionable information. Since the current hop-to-hop text doesn't require messages to follow the same routes inbound and outbound, an AckRequested/From element might be useful -- letting the receiver know where to send the Acknowledgment in cases where it must be sent separately. Probably would be better to remove Acknowledgment/From since it covers only 1 of the 4 values hop-to-hop implementations might want to log. Other alternative is From and To in both AckRequested and Acknowledgment.
Proposal: remove Acknowledment/From element
Resolution: none
43 line 2304(148) Appendix A schema technical Active Chris Ferris
Title: Description element here doesn't match the document
Description: [see email] Description element here doesn't match the document. We'd much prefer leaving the schema as is and correcting the document's poor description of this element and an "empty content" case. None of the other Description element occurrences in the text go so far away from standard practice as section 4.2.3.2.6. (Probably not good to mention w.r.t. schema at all.)
Proposal:
Resolution: none
44 line 2282(126) Appendix A schema major technical Active Chris Ferris
Title: sequenceNumber.type is poorly defined
Description: [see email] sequenceNumber.type is poorly defined. The base type for the element content must be nonNegativeInteger (not positiveInteger) to allow the oft-mentioned "0" value. Even better, should define a type derived from nonNegativeInteger with a maxExclusive="99999999" attribute and use that here (guess the attribute can be added in the element def'n as well). Going even one step better to avoid leading zeroes and the plus sign (as uselessly required by the documentation), could use pattern="0|([1-9][0-9]{0,7})", making the min and max values redundant.
Proposal: change base type of sequenceNumber.type to nonNegativeInteger
Resolution: none
45 line 2374(???) Appendix A schema editorial Active Chris Ferris
Title: headerExtension.grp attribute group should be derived by extension from the bodyExtension.grp
Description: [see email] Why isn't the headerExtension.grp attribute group derived by extension from the bodyExtension.grp? That would be a bit more clear.
Proposal:
Resolution: none
46 line 2397(240) & 2403(248) Appendix A schema editorial Active Chris Ferris
Title: Role element is used twice but not defined in a common location
Description: [see email] Role element is used twice but not defined in a common location. Suggest defining Role at the top level and referring to that definition here. These are the only times <element> appears in the schema with a type attribute but not at the top level (not defining a global element).
Proposal:
Resolution: none
47 none Appendix A schema technical Active Chris Ferris
Title: Schema element should have an optional "namespace" attribute
Description: [see email] It was proposed in this email that the Schema element have an optional "namespace" attribute. This was raised as a technical issue but not addressed.
Proposal:
Resolution: none
48 line 2169(???) Appendix A schema technical Active Chris Ferris
Title: Import correct / latest schema for XML namespace
Description: [see email] should reference http://www.w3.org/2001/03/xml.xsd in the import statement instead of the "hacked" version currently cited.
Proposal: 2169 should reference http://www.w3.org/2001/03/xml.xsd in the import statement instead of the "hacked" version currently cited.
Resolution: none

Table Legend

id
Issue number
Title
Short title/name of the issue
Spec
Document referred to in issue (AM = Abstract Model, Spec = XMLP/SOAP Specification
Description
Short description of issue, possibly including link to origin of issue
Section
Reference to specification section that motivated this issue
Topic
Rough topic categorisation, one of: env(elope), rpc, enc(oding), meta(issue), bind(ing), fault
Class
Design or Editorial
Status
One of: Unassigned, Active, Closed, Postponed
Proposal
Current proposal for resolution of issue, possibly including link to further text
Resolution
Short description of resolution, possibly including link to a more elaborate description
Raised by
Person who raised the issue
Owner
ebXML Messaging TC Member responsible for the issue
Maintained by Christopher Ferris.
<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="ebxml-msg-issues-html.xsl" type="text/xsl"?>
<!DOCTYPE issues SYSTEM "ebxml-msg-issues.dtd" >
<issues update='January 30, 2002'>
<issue>
<issue-num>1</issue-num>
<title>title page</title>
<locus>line 15/16</locus>
<section>title page</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a>the date cited here should be consistent
    with its adoption as a TC, not the date that the
    document was published to the TC for consideration
    (vote). Given that the ballot is closed as of
    January 18, then the date cited here cannot be
    less than that date.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>2</issue-num>
<title>boilerplate</title>
<locus>line 17/18</locus>
<section>title page</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> either the tense is incorrect (is presented)
    or this should be removed. Suggest that the latter be
    applied. In the event that the OASIS membership
    does approve the TC specification as an OASIS Standard,
    then I could see adding something to that effect.
</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>3</issue-num>
<title>title page</title>
<locus>line 20</locus>
<section>title page</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> need to update the URI reference here. Should follow
    w3c approach and have a stable URI that people can reference
    which will always have the latest draft, in addition to an
    explicit URI for the specific reference to a specific draft
    for use in external references, etc.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>4</issue-num>
<title>ebXML participants</title>
<locus>line 23</locus>
<section>ebXML participants</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> I agree that having this section (ebXML Participants)
    in addition to the one in the appendix is both gratuitous
    and confusing. Suggest that we have but a single list, and
    that that list be in an appendix, if anywhere. There is
    no reason to cite the participants of the original ebXML
    project team.</description>
<proposal>remove section "ebXML Participants"</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>5</issue-num>
<title>ebXML Participants</title>
<locus>line 26</locus>
<section>ebXML participants</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> If the section is preserved (see issue 4), then
    s/meeting/meetings/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>6</issue-num>
<title>typo</title>
<locus>line 200</locus>
<section>Introduction</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/sending and receiving/that sends and receives/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>7</issue-num>
<title>typo</title>
<locus>line 208</locus>
<section>Introduction</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/,//</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>8</issue-num>
<title>editorial tweak</title>
<locus>line 214</locus>
<section>Introduction</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/Elements/Features/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>9</issue-num>
<title>editorial tweak</title>
<locus>line 472</locus>
<section>2.1 Packaging Specification</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/the following figure/figure 2.1/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>10</issue-num>
<title>RFC2119 usage</title>
<locus>line 509</locus>
<section>2.1.2 Message Package</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/may/can/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>11</issue-num>
<title>confusion w/r/t conformance</title>
<locus>line 709</locus>
<section>2.3.8 version attribute</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> this is going to lead to all manner of confusion.
    For conformance to THIS specification, all of the version
    attributes on any SOAP extension elements defined in THIS
    specification MUST have a value of  "2.0".

    An ebXML message MAY contain SOAP header extension elements
    that have a value other than "2.0". An implementation
    conforming to this specification that receives a message
    with ebXML SOAP extensions qualified with a version other
    than "2.0" MAY process the message if it recognizes the
    version identified and is capable of processing it. It
    MUST respond with an error (details TBD) if it does not
    recognize the identified version.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>12</issue-num>
<title>editorial tweak</title>
<locus>line 724</locus>
<section>2.3.10 NextMSH actor URI</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/The /The URI /</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>13</issue-num>
<title>editorial tweak</title>
<locus>line 732</locus>
<section>2.3.11 ToPartyMSH actor URI</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/The /The URI /</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>14</issue-num>
<title>RFC2119 usage/typo</title>
<locus>line 764</locus>
<section>3.1.1 From and To Party elements</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/must/MUST/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>15</issue-num>
<title>RFC2119 usage</title>
<locus>line 784</locus>
<section>3.1.1.2 PartyId element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> use of the term OPTIONAL here may be confusing
    given the conformance statement. Suggest that this be
    rephrased as follows:

    The Role element, if present, ...
    (technical/editorial)

    Other instances of OPTIONAL where ordinality is meant:

         * 500 (MIME start parameter)
         * 1801, 1814 (Signature element in Message Status
    Request &amp; Response)
         * 1822, 1842 (StatusRequest and StatusResponse
    elements; really, the service is OPTIONAL)
         * 1905, 1955 (Signature element in Ping &amp; Pong)</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>16</issue-num>
<title>replacement text for Note</title>
<locus>line 788</locus>
<section>3.1.1.2 Role element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> suggested replacement text for the Note:

    Note: Use of a URI for the value of the Role element
    is RECOMMENDED. e.g. http://rosettanet.org/roles/buyer</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>17</issue-num>
<title>CPA</title>
<locus>line 810</locus>
<section>3.1.2 CPAId element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> given that we agreed in the f2f that there *was*/*is*
    a CPA, this sentence should be removed so as to avoid any
    unnecessary confusion.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>18</issue-num>
<title>typo</title>
<locus>line 831</locus>
<section>3.1.3 ConversationId element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description>s/schema/scheme/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>19</issue-num>
<title>local part of MID?</title>
<locus>line 872</locus>
<section>3.1.6.1 MessageId element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> We thought that an issue had been raised that challenged
    the "local part" characterization.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>20</issue-num>
<title>duplicate detection</title>
<locus>line 899</locus>
<section>3.1.7 DuplicateElimination element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> While it may be true that in order to ensure that
    duplicates are detected and prevented from being forwarded
    to the application, a persistent store is required,
    it is not a request by the sender that
    the receiver have a persistent store, it is a request by
    the sender that the receiver filter duplicate messages
    such that the application does not receive them.
    This section needs a better description.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>21</issue-num>
<title>duplicate elimination confusion</title>
<locus>line 901</locus>
<section>3.1.8 DuplicateElimination element</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> This too is going to be confusing to the reader.
    The semantics of duplicate elimination are such that the
    application that is to process the received message need
    not concern itself that it might be processing a duplicate
    message. The delivery semantics of this element alone might
    be either at-most-once or best-effort, but in conjunction
    with acknowledgments, retries, etc., can effect delivery
    semantics of once-and-only-once.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>22</issue-num>
<title>"if there is a CPA with ..." is a little too vague</title>
<locus>line 903</locus>
<section>3.1.8 DuplicateElimination element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> "if there is a CPA with ..." is a little too vague.
    This is related to the issue raised recently on the list[3].
    We prefer that we be a bit more specific. Suggested text:

    The DuplicateElimination element MUST NOT be present if
    the DeliveryChannel for the message in the CPA identified
    by CPAId has a value of "never". The DuplicateElimination
    element MUST be present if the DeliveryChannel for the
    message in the CPA identified by CPAId has a value of
    "always". </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>23</issue-num>
<title>example issue</title>
<locus>line 914</locus>
<section>3.1.9 MessageHeader example</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> (example) curious that the From party has no
    identified Role, but the To party does. Suggest that
    both be assigned a role or neither. </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>24</issue-num>
<title>premature reference to xlink:role</title>
<locus>line 942</locus>
<section>3.2 Manifest element</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> this sentence seems premature since xlink:role is
    an attribute of Reference element which has not yet been
    defined. Suggest moving this sentence to the bullet
    defining xlink:role below (after line #961)</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>25</issue-num>
<title>Description element</title>
<locus>line 972, 1321</locus>
<section>3.2.1.2 Description element</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> The Description element defined in section 3.1.8
    identifies the purpose of the Description element as
    describing the message. The Description element here
    is intended to provide for a description of the payload
    document identified by the Reference item. The
    structure/syntax of the element may be the same, but
    the purpose is quite different.

    Suggest that we reference the structure of the description
    element, but that we augment the definition here (and
    elsewhere throughout the spec)  with the specific purpose
    of the element in the current context.

    In addition, the definition of the Description element
    at times conflicts with the schema (esp sect. 4.2.3.2.6). The
    Description element MUST not be empty as it extends
    non-empty-string. </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>26</issue-num>
<title>suggestion to discard note</title>
<locus>line 982</locus>
<section>3.2.2 Manifest validation</section>
<priority>minor technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Chris previously sent a note suggesting that this
    Note be discarded. It isn't at all clear that  it adds
    any value. Would add to text (or note) in section 3.2.2 that the
    xlink:href may be a Content-Location or a Content-ID
    as described in section 4.1.3, lines 1084-1089.
    If the ds:Reference element may have a URI of this
    type and that URI must match the xlink:href of some
    "corresponding" eb:Reference element, options must
    be similar. </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>27</issue-num>
<title>RFC2119 usage</title>
<locus>line 1029</locus>
<section>4.1.2.1 Collaboration Protocol Agreement</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/may be/is/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>28</issue-num>
<title>typo</title>
<locus>line 1037</locus>
<section>4.1.3 Signature Generation</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/and //</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>29</issue-num>
<title>editorial tweak</title>
<locus>line 1050</locus>
<section>4.1.3 Signature Generation</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description>s/for the ebXML Message Service//</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>30</issue-num>
<title>RFC2119 MUST semantics for DFN</title>
<locus>line 1434</locus>
<section>7 Reliable Messaging Module</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> This was supposed to have been changed to MUST.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>31</issue-num>
<title>duplicate eleimination characterization</title>
<locus>line 1436</locus>
<section>7 Reliable Messaging Module</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> The method of duplicate elimination is not achieved
    via a persistent store, but is facilitated by same.
    The mechanism by which duplicates are detected and
    eliminated is via the MessageId. This is likely
    to become a source of confusion.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>32</issue-num>
<title>RFC2119 usage</title>
<locus>line 1449</locus>
<section>7.1 Persistent Storage...</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/SHOULD/MUST/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>33</issue-num>
<title>editorial tweak</title>
<locus>line 1459</locus>
<section>7.2 Methods ...</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/structures/extension modules/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>34</issue-num>
<title>error on ack and ack on error issue</title>
<locus>line 1512</locus>
<section>7.3.1.4 AckRequested</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> We agreed that an error message could be sent
    reliably. You are only precluded from requesting an
    acknowledgment on a message that itself is an acknowledgment
    message. </description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>35</issue-num>
<title>typo</title>
<locus>line 1564</locus>
<section>7.3.2.5 [XMLDSIG] Reference</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> s/This/The/</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>36</issue-num>
<title>error on ack</title>
<locus>line 1580</locus>
<section>7.3.2.8 Acknowledgment...</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> We did NOT agree to this at all. We
    agreed that an Error message *could* be sent reliably.
    Ref <a href='http://lists.oasis-Active.org/archives/ebxml-msg/200201/msg00036.html'>email</a> for discussion.</description>
<proposal>apply original TC resolution</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>37</issue-num>
<title>incorrect URI</title>
<locus>line 1809</locus>
<section>8.1.2 MessageStatus...</section>
<priority>technical</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> URI s/b urn:oasis:names:tc:ebxml-msg:service</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>38</issue-num>
<title>duplicate content with 11.1.4</title>
<locus>line 2054...</locus>
<section>11 Multihop...</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> this is essentially duplicate of the content of
    section 11.1.4, suggest it be deleted.</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>39</issue-num>
<title>references to ebXML specs</title>
<locus>line 2791...</locus>
<section>Non-Normative References</section>
<priority>editorial</priority>
<topic>spec</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> references to ebXML specs should be qualified by
    their URI, and as previously cited, the ebRS reference
    should probably cite the 2.0 version of their spec(s).</description>
<proposal>make suggested change</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>40</issue-num>
<title>restore comment in schema</title>
<locus>line 2245(95)</locus>
<section>Appendix A</section>
<priority>editorial</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Comment from last draft-msg-header-05.xsd had a useful
    annotation mentioning the soap:actor element in
    SyncReply MUST have the value
        http://schemas.xmlsoap.org/soap/actor/next
    Suggest restoring that inline documentation.</description>
<proposal>restore comment</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>41</issue-num>
<title>Acknowledgment/RefToMessageId
    element should be removed</title>
<locus>line 2281(125)</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Doug raised an issue[1] that the Acknowledgment/RefToMessageId
    element should be removed.  It remains in the document and
    the schema but should be removed.  An Acknowledgment element
    should be included if and only if the overall message
    refers to the original one of interest.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>42</issue-num>
<title>Acknowledgment/From element is not particularly useful</title>
<locus>line 2282(126)</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Doug believes he mentioned this before w.r.t. the document.
    The Acknowledgment/From element is not particularly useful
    because it provides the Receiving MSH no actionable information.
    Since the current hop-to-hop text doesn't require messages
    to follow the same routes inbound and outbound, an
    AckRequested/From element might be useful -- letting the
    receiver know where to send the Acknowledgment in cases
    where it must be sent separately.  Probably would be better
    to remove Acknowledgment/From since it covers only 1 of the 4
    values hop-to-hop implementations might want to log.
    Other alternative is From and To in both AckRequested and
    Acknowledgment.</description>
<proposal>remove Acknowledment/From element</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>43</issue-num>
<title>Description element here doesn't match the document</title>
<locus>line 2304(148)</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Description element here doesn't match the document.  We'd
    much prefer leaving the schema as is and correcting the
    document's poor description of this element and an
    "empty content" case.  None of the other Description
    element occurrences in the text go so far away from
    standard practice as section 4.2.3.2.6.  (Probably not good
    to mention w.r.t. schema at all.)</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>44</issue-num>
<title>sequenceNumber.type is poorly defined</title>
<locus>line 2282(126)</locus>
<section>Appendix A</section>
<priority>major technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> sequenceNumber.type is poorly defined.  The base type for
    the element content must be nonNegativeInteger (not
    positiveInteger) to allow the oft-mentioned "0" value.
    Even better, should define a type derived from
    nonNegativeInteger with a maxExclusive="99999999" attribute
    and use that here (guess the attribute can be added in
    the element def'n as well).  Going even one step better to
    avoid leading zeroes and the plus sign (as uselessly required
    by the documentation), could use pattern="0|([1-9][0-9]{0,7})",
    making the min and max values redundant.</description>
<proposal>change base type of sequenceNumber.type to nonNegativeInteger</proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>45</issue-num>
<title>headerExtension.grp attribute group should be derived by
    extension from the bodyExtension.grp</title>
<locus>line 2374(???)</locus>
<section>Appendix A</section>
<priority>editorial</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Why isn't the headerExtension.grp attribute group derived by
    extension from the bodyExtension.grp?  That would be a
    bit more clear.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>46</issue-num>
<title>Role element is used twice but not defined in a common location</title>
<locus>line 2397(240) &amp; 2403(248)</locus>
<section>Appendix A</section>
<priority>editorial</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> Role element is used twice but not defined in a common
    location.  Suggest defining Role at the top level and
    referring to that definition here.  These are the only times
    &lt;element> appears in the schema with a type attribute but
    not at the top level (not defining a global element).</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>47</issue-num>
<title>Schema element should have an optional
    "namespace" attribute</title>
<locus>none</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> It was proposed in this <a href='http://lists.oasis-Active.org/archives/ebxml-msg/200111/msg00323.html'>email</a> that the Schema element have an optional
    "namespace" attribute. This was raised as a technical
    issue but not addressed.</description>
<proposal></proposal>
<resolution>none</resolution>
</issue>
<issue>
<issue-num>48</issue-num>
<title>Import correct / latest schema for XML namespace</title>
<locus>line 2169(???)</locus>
<section>Appendix A</section>
<priority>technical</priority>
<topic>schema</topic>
<status>Active</status>
<originator><a href='mailto:chris.ferris@sun.com'>Chris Ferris</a></originator>
<responsible></responsible>
<description><a href='http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html'>[see email]</a> should reference <a href='http://www.w3.org/2001/03/xml.xsd'>http://www.w3.org/2001/03/xml.xsd</a> in
    the import statement instead of the "hacked" version
    currently cited.</description>
<proposal>2169 should reference <a href='http://www.w3.org/2001/03/xml.xsd'>http://www.w3.org/2001/03/xml.xsd</a> in
    the import statement instead of the "hacked" version
    currently cited.</proposal>
<resolution>none</resolution>
</issue>
<maintainer>
<fullname>Christopher Ferris</fullname>
<uri>mailto:chris.ferris@sun.com</uri>
</maintainer>
</issues>

<!-- This is the DTD for the XMLP WG issues list:
     http://www.w3.org/2000/xp/Group/xmlp-issues.xml
     Ideally, the XMLspec DTD could be used.
     $Id: 28-xmlp-issues.dtd,v 1.11 2001/11/06 14:00:56 hugo Exp $

     Copyright (c) 2001 W3C (Massachusetts Institute of Technology,
     Institut National de Recherche en Informatique et en Automatique,
     Keio University). All Rights Reserved.
     http://www.w3.org/Consortium/Legal/

     This document is governed by the W3C Software License [1] as
     described in the FAQ [2].

     [1] http://www.w3.org/Consortium/Legal/copyright-software-19980720
     [2] http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620.html#DTD

     January 30, 2002: Chris Ferris
       - modified for ebxml-msg TC usage
     August 28, 2001: Hugo Haas <hugo@w3.org>
       - First version to make my psgml mode happy
-->

<!-- Root element -->
<!ELEMENT issues ( issue+, maintainer+ ) >
<!ATTLIST issues update CDATA #REQUIRED >

<!-- A few useful entities -->

<!-- A few parameter entities -->
<!ENTITY % desc '#PCDATA | a | br | p | pre | ul | em'>
<!ENTITY % somebody '#PCDATA | a'>

<!-- Maintainer -->

<!ELEMENT maintainer ( initials?, fullname, uri )>
<!ELEMENT initials ( #PCDATA ) >
<!ELEMENT fullname ( #PCDATA ) >
<!ELEMENT uri ( #PCDATA ) >

<!-- Issue -->

<!ELEMENT issue ( issue-num, title, locus, section, priority, topic, status, originator, responsible, description, proposal, resolution ) >

<!-- Issue number -->
<!ELEMENT issue-num ( #PCDATA ) >

<!-- Title of the issue -->
<!ELEMENT title ( %desc; )* >

<!-- Document referred to in the issue:
     Spec = SOAP Version 1.2 specification
     AM = XML Protocol Abstract Model -->
<!ELEMENT locus ( #PCDATA ) >

<!-- Description of the issue, proposal for resolution,
     and resolution -->
<!ELEMENT description ( %desc; )* >
<!ELEMENT proposal ( %desc; )* >
<!ELEMENT resolution ( %desc; )* >

<!-- Topic of the issue:
     env(elope)
     rpc
     enc(oding)
     meta(issue)
     bind(ing)
     fault
-->
<!ELEMENT topic ( #PCDATA ) >

<!-- Status of the issue:
     Unassigned
     Active
     Closed
     Postponed
-->
<!ELEMENT status ( #PCDATA ) >

<!-- Class of the issue:
     Design
     Editorial
-->
<!ELEMENT priority ( #PCDATA ) >

<!-- Requirement related to the issue:
     Requirement number, n/a, or empty
-->
<!ELEMENT section ( #PCDATA | a )* >

<!-- Originator and fault owner -->
<!ELEMENT originator ( %somebody; )* >
<!ELEMENT responsible ( %somebody; )* >

<!-- Mimicing XHTML mark-up -->

<!ELEMENT a ( #PCDATA ) >
<!ATTLIST a href CDATA #REQUIRED >

<!ELEMENT em ( #PCDATA ) >

<!ELEMENT p ( #PCDATA | a | br | em)* >
<!ELEMENT pre ( #PCDATA | a )* >

<!ELEMENT ul ( li+ ) >
<!ELEMENT li ( #PCDATA ) >

<!ELEMENT br EMPTY >

<?xml version="1.0" ?> 
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<!--
  Style sheet for converting xmlp-issues.xml into a static HTML
  document
        January 28, 2002 (CBF)
          adapted from XML Protocol WG Issues List XSLT.
        November 6, 2001 (HH)
          Not using the initials thingy anymore.
        October 16, 2001 (HH)
          Added list of maintainer.
        October 3, 2001 (HH)
          Removed closed issues from the summary table.
        October 3, 2001 (HH)
          Added an explanation of the acronyms used.
        September 25, 2001 (HH)
          Added support for em.
	September 18, 2001 (HH)
	  Added a few spaces.
        September 6, 2001 (HH)
          Now referencing xmlp-comments.
        September 6, 2001 (HH)
          Changed order in the summary from alphabetical to:
          Active, Unassigned, Postponed, Closed
          Fixed order of locus to:
          Spec, AM
        August 24, 2001 (HH)
          Added template for <pre>, and removed the one for text()
          which was unnecessary.
        June 20, 2001 (HH)
          Added some colors to make the list clearer
        June 3, 2001 (DCF)
          Added subheading to show xmlp-issues.xml (up)date
        May 30, 2001 (DCF)
          Added support for topic and title fields
        May 24, 2001 (DCF)
          Added summary table, doctype and style statements
        May 23, 2001 (DCF)
          Added support for proposal tag, reworded table text
        May 16, 2001 (DCF)
          Added default sort by issue number
        May 14, 2001 (DCF)
          Initially created

  $Id: xmlp-issues-html.xsl,v 1.18 2001/11/06 10:53:18 hugo Exp $
-->

<xsl:strip-space elements="*"/>
<xsl:output
   method="html"
   encoding="iso-8859-1"
   omit-xml-declaration="yes"
   doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"
   />

<xsl:template match="/">
  <html>
    <head>
      <title>OASIS ebXML Message Service TC Issues List</title>

      <style type="text/css">
         body {color: black; background: white;}
         .Closed { background-color: #888888; }
      </style>

    </head>
    <body>
    <table><tr><td width="5%" align="center" valign="middle">
    <a href="http://oasis-open.org/">
    <img src="http://oasis-open.org/images/oasis_logo.gif" alt="OASIS" 
    bgcolor="#3c1a57"
    height="46"
    width="131" border="0"/></a>
    </td><td width="95%">
    <a href="http://oasis-open.org/committees/ebxml-msg">OASIS ebXML Messaging TC</a>
    </td></tr></table>

    <h1>OASIS ebXML Messaging TC Issues List</h1>
    
    <h3>Last update: <xsl:value-of select="issues/@update"/></h3>
    
    <p>Issues regarding the <a href="./#drafts">documents produced by
    the OASIS ebXML Messaging TC</a> should be reported to <a
    href="mailto:ebxml-msg@lists.oasis-open.org">ebxml-msg@lists.oasis-open.org</a> (<a
    href="http://lists.oasis-open.org/archives/ebxml-msg/">public
    archives</a>).</p>

    <p>Comments on this list should be sent to the
    <a href="mailto:ebxml-msg@lists.oasis-open.org">ebxml-msg@lists.oasis-open.org</a>
    mailing
    list (<a
    href="http://lists.oasis-open.org/archives/ebxml-msg/">Archives</a>).</p>

	<p></p>

    <ul>
      <li><a href="#summaryList">Summary list of outstanding issues</a></li>
      <li><a href="#detailList">Detailed list of issues</a></li>
      <li><a href="#legend">Legend for detailed list</a></li>
    </ul>
     
    <xsl:apply-templates mode="summary" />
    <xsl:apply-templates mode="detail" />

    <hr/>

	<xsl:apply-templates select="issues/maintainer" />

    </body>
  </html> 
</xsl:template>

<xsl:template match="issues" mode="summary">
  <h2><a name="summaryList"></a>Summary List of Outstanding Issues</h2>
  <table border='1'>
      <tr>
        <th><a href="#id">id</a></th>
        <th><a href="#Status">Status</a></th>
        <th><a href="#Spec">Spec</a></th>
        <th><a href="#Topic">Topic</a></th>
        <th><a href="#Class">Class</a></th>
        <th><a href="#Section">Section</a></th>
        <th><a href="#Title">Title</a></th>
      </tr>
    <xsl:apply-templates select="issue[child::status!='Closed']"
	mode="summary">
      <xsl:sort select="status='Postponed'" />
      <xsl:sort select="status='Unassigned'" />
      <xsl:sort select="status='Active'" />
      <xsl:sort select="topic" order="descending"/>
      <xsl:sort select="priority" />
      <xsl:sort data-type="number" select="issue-num" />
    </xsl:apply-templates>
  </table>
</xsl:template>

<xsl:template match="issue" mode="summary">
      <tr>
        <td>
          <a href="#x{issue-num}">
            <xsl:value-of select="issue-num"/>
          </a>
        </td>
        <td><xsl:value-of select="status"/></td>
        <td><xsl:value-of select="locus"/></td>
        <td><xsl:value-of select="topic"/></td>
        <td><xsl:value-of select="priority"/></td>
        <td><xsl:value-of select="section"/></td>
        <td><xsl:value-of select="title"/></td>
      </tr>
</xsl:template>

<xsl:template match="issues" mode="detail">
   <h2><a name="detailList"></a>Detailed List of Issues</h2>
  <table border='1'>
      <tr>
        <th><a href="#id">id</a></th>
        <th><a href="#Spec">Spec</a></th>
        <th><a href="#Section">Section</a></th>
        <th><a href="#Topic">Topic</a></th>
        <th><a href="#Class">Class</a></th>
        <th><a href="#Status">Status</a></th>
        <th><a href="#Raised by">Raised By</a></th>
        <th><a href="#Owner">Owner</a></th>
      </tr>
    <xsl:apply-templates select="issue" mode="detail">
      <xsl:sort data-type="number" select="issue-num" />
    </xsl:apply-templates>
  </table>
  <h2><a name="legend">Table Legend</a></h2>
   <dl>
   <dt><a name="id">id</a></dt>
   <dd>Issue number</dd>
   <dt><a name="title">Title</a></dt>
   <dd>Short title/name of the issue</dd>
   <dt><a name="Spec">Spec</a></dt>
   <dd>Document referred to in issue (AM = Abstract Model, Spec = XMLP/SOAP Specification</dd>
   <dt><a name="Description">Description</a></dt>
   <dd>Short description of issue, possibly including link to origin of issue</dd>
   <dt><a name="Section">Section</a></dt>
   <dd>Reference to specification section that motivated this issue</dd>
   <dt><a name="Topic">Topic</a></dt>
   <dd>Rough topic categorisation, one of: env(elope), rpc, enc(oding), meta(issue), bind(ing), fault</dd>
   <dt><a name="Class">Class</a></dt>
   <dd>Design or Editorial</dd>
   <dt><a name="Status">Status</a></dt>
   <dd>One of: Unassigned, Active, Closed, Postponed</dd>
   <dt><a name="Proposal">Proposal</a></dt>
   <dd>Current proposal for resolution of issue, possibly including link to further text</dd>
   <dt><a name="Resolution">Resolution</a></dt>
   <dd>Short description of resolution, possibly including link to a more elaborate description</dd>
   <dt><a name="Raised">Raised by</a></dt>
   <dd>Person who raised the issue</dd>
   <dt><a name="Owner">Owner</a></dt>
   <dd>ebXML Messaging TC Member responsible for the issue</dd>
   </dl>
</xsl:template>

<xsl:template match="issue" mode="detail">
                <tbody class="{status}">
      <tr>
        <xsl:apply-templates select="issue-num" mode="detail" />
        <xsl:apply-templates select="locus" mode="detail" />
        <xsl:apply-templates select="section" mode="detail" />
        <xsl:apply-templates select="topic" mode="detail" />
        <xsl:apply-templates select="priority" mode="detail" />
        <xsl:apply-templates select="status" mode="detail" />
        <xsl:apply-templates select="originator" mode="detail" />
        <xsl:apply-templates select="responsible" mode="detail" />
      </tr>
      <tr>
        <xsl:apply-templates select="title" mode="detail" />
      </tr>
      <tr>
        <xsl:apply-templates select="description" mode="detail" />
      </tr>
      <tr>
        <xsl:apply-templates select="proposal" mode="detail" />
      </tr>
      <tr>
        <xsl:apply-templates select="resolution" mode="detail" />
      </tr>
                     </tbody>
</xsl:template>

<xsl:template match="issue-num" mode="detail">
  <td rowspan='5' valign='top'>
    <b><a name="x{.}"><xsl:value-of select="."/></a></b> 
  </td>
</xsl:template>

<xsl:template match="locus" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="section" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="topic" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="priority" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="status" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="originator" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="responsible" mode="detail">
  <td>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="title" mode="detail">
  <td colspan='7'>
    <b>Title:</b>
    <xsl:text> </xsl:text>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="description" mode="detail">
  <td colspan='7'>
    <b>Description:</b>
    <xsl:text> </xsl:text>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="proposal" mode="detail">
  <td colspan='7'>
    <b>Proposal:</b>
    <xsl:text> </xsl:text>
    <xsl:apply-templates />
  </td>
</xsl:template>

<xsl:template match="resolution" mode="detail">
  <td colspan='7'>
    <b>Resolution:</b>
    <xsl:text> </xsl:text>
    <xsl:apply-templates />
  </td>
</xsl:template>

<!-- Sign the document -->

  <xsl:template match="maintainer">
    <address>
      <small>
	Maintained by <a href="{uri}"><xsl:value-of select="fullname"/>.</a>
      </small>
    </address>
  </xsl:template>

<!-- HTML like stuff -->

<xsl:template match="a[@href]">
    <a>
      <xsl:attribute name="href">
        <xsl:value-of select="@href"/>
      </xsl:attribute>
      <xsl:apply-templates />
    </a>
</xsl:template>

<xsl:template match="a[@name]">
    <a>
      <xsl:attribute name="name">
        <xsl:value-of select="@name"/>
      </xsl:attribute>
      <xsl:apply-templates />
    </a>
</xsl:template>

<xsl:template match="pre">
  <pre>
    <xsl:apply-templates />
  </pre>
</xsl:template>

<xsl:template match="p">
  <p>
    <xsl:apply-templates />
  </p>
</xsl:template>

<xsl:template match="em">
  <em>
    <xsl:apply-templates />
  </em>
</xsl:template>

<xsl:template match="ul">
  <ul>
    <xsl:for-each select="li">
      <li><xsl:apply-templates /></li>
    </xsl:for-each>
  </ul>
</xsl:template>

</xsl:stylesheet>

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

Powered by eList eXpress LLC