OASIS ebXML Messaging Services TC

 View Only

  • 1.  [ebxml-msg] issues list

    Posted 01-30-2002 15:41 
    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
    




    OASIS 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>


Related Content