Re: Test assertion markups for SOAP/JMS spec completed

On Tue, 17 Jun 2008, Eric Johnson wrote:

> 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
> following:
> 
> Editorial changes:
>  *  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]."

Are you sure you want to restrict to URIs only? In SOAP 1.2 [1], IRIs are 
allowed (provided they are encoded in form of URIs). What forbid using 
IRIs at a higher level, then encode in URI when needed ?

>  *  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
>     property definition.
>  *  Section 2.5: Sentence "relevant information..." is probably spurious
>  *  Section 2.6: Parenthetical "(sending and receiving)" does not appear
>     to add to the clarity of the text for both bullet points.
>  *  Section 2.6.1.1: 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 - inconsistent.
>  *  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..."
> Content questions:
>  *  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
>     equivalent.
>  *  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?
> -Eric.
> 
> 
> 
>

[1] <http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#useofuris>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Wednesday, 18 June 2008 09:33:04 UTC