RE: Closing issue 219

Glen, WG,

I have some further comments below. 

I'm a little uncomfortable with the replacement text for section 3.1 which I
explain (I hope) below and have suggested an 'improvement'. 

I've also suggested 'improvements' (substantially editorial) to both pieces
of text suggested for Section 3.2.

Many thanks,


> -----Original Message-----
> From: Glen Daniels []
> Sent: 02 August 2002 15:05
> To: ''; ''
> Cc: ''
> Subject: Closing issue 219
> Hi folks!
> On July 31st, the WG agreed to close issue #219 [1] as follows:
> Replace the sentence in section 3.1 beginning with "A feature 
> expressed as SOAP headers..." with the following:
> "When a feature is expressed this way, the combined syntax 
> and semantics of such headers are known as a SOAP Module, and 
> are specified according to the rules in section 3.2 SOAP Modules."

The text generated by the WG implies that a module only ever 'expresses' a
single feature. I believe that a module (just as a binding) may realise
(specify the *how* of) several features intended for use in combination and
address the the practial concerns of the dependence and interaction between
the use of such features in combination.

"A SOAP Module describes/specifies the syntax and semantics of SOAP headers
used to express the functionality of one or more particular features. SOAP
Modules are are specified according to the rules in section 3.2 SOAP

I think this retains the spirit of the WG's text and clarifies that a SOAP
module may realise/provide multiple features.

> Then replace the first two sentences of 3.2 with:
> "The term 'SOAP Module' refers to the set of syntax and 
> semantics associated with implementing a particular feature 
> (link to 3.1) as SOAP headers.  A Module is described in a 
> Module Specification, which adheres to the following rules.  It:"

I'm mostly ok with this... but I'd like it to say "...associated with
implementing one or more particular features using SOAP headers. ..."

> Further, we agreed to insert the following as the new second 
> rule in section 3.2, moving the other rules down one:
> "2. MUST, *if* the Module implements a Feature which has 
> already been defined elsewhere, clearly refer to said 
> Feature's URI.  Note that a Module may EITHER explicitly 
> refer to a separate Feature in this way OR may implicitly 
> define a Feature simply by describing the semantics of the Module."

OK... I think the spirit is right, although a sentence starting with the
embolden MUST followed by a conditional seems tortured. Would suggest
rewording the first sentence as:

"2. A Module that implements a Feature which has already been defined
elsewhere MUST clearly refer to the said Feature's URI."

...although "refer to ... URI"  also feels awkward... does that URI have a
URI that may be used refer to the referent?

Suggest: "...reference the said Feature using the Features URI."

> (note that this last bit relies on a Feature having a URI, 
> which is dealt with by the resolution of issue #230 [2])
> Please send any comments to xml-dist-app.
> Thanks!
> --Glen
> [1]
> [2]

Received on Wednesday, 14 August 2002 07:24:01 UTC