Given Peter's complete run through, it appears that he noted several
editoral/content issues not related to testing. Seems to me that we
should turn that into a list for us to resolve the issues, and or have
the editors apply changes. So I thought it useful to put together the
- Document refers to IRI scheme instead of URI throughout. Should
be changed to URI. Sections 1.1, 1.5, 2.2, 2.2.1, 2.2.2, 2.2.3, 2.2.4,
2.2.5, 2.3, 3.2, 3.3, 3.4.1, 3.4.5, 3.5,
- Section 1.1: Third bullet currently reads "The IRI specification
for ..." -- suggestion to change to "How the SOAP over JMS uses the
[URI Scheme for JMS]."
- Section 2.2: Better wording for sentence reading "If a property
is specified in more than one..."
- Section 2.4: reference "(section 3.3)" should be replaced by
reference to section 2.2.3, or an explicit link to the contentType
- Section 2.5: Sentence "relevant information..." is probably
- Section 2.6: Parenthetical "(sending and receiving)" does not
appear to add to the clarity of the text for both bullet points.
- Section 126.96.36.199: references "section 4". Should be a link
to section 2.4 instead.
- Section 2.6.2: "apply to both ... until stated otherwise" should
change "until" to "unless". Actually - I don't see any further
qualification of SOAP 1.1 vs. 1.2 behavior here, so the entire clause
might be unnecessary.
- Section 2.7.1 & 2.7.2: URLs not in monospaced type -
- Section 2.8: inconsistentMEP not linked to its definition.
- Section A (references): URI scheme for JMS references wrong URL
"..jms-iri-03..." instead of "...jms-uri-03..."
- Section 1.1: Do we want to specify actual JMS calls? While we
don't want to make the specific calls mandatory, we could require the
- Section 1.5: What do we really mean by "MUST fully support the
JMS IRI [sic] scheme"? That is, should we should we spell out
"support" in this context? (If I recall correctly, I take blame for
the weak wording here - sorry.)
- Section 2.2.2: Do we mandate that property "replyToName" is only
used for a two-way MEP?
- Section 2.2.3: contentType - Do we need to add statements
requiring minimal support for various flavors of XML, or require that
vendors support specific encodings?
- Section 2.2.3: We define a "requestIRI" property. Do we want to
change this to a requestURI property, but allow users to put an IRI in
the contents? This will have a cascade effect in other places....
- Section 2.2.4: Definition of fault codes with "IRI" in the name -
do we want to change them to use URI?
- Section 2.7.2: If this is untestable, should we be specifying it?