Re: Edits to part 2

On Fri, 30 Jul 2004 11:10:28 -0400
Glen Daniels <gdaniels@sonicsoftware.com> wrote:
> > On Thu, 29 Jul 2004 18:10:05 -0400
> > Glen Daniels <gdaniels@sonicsoftware.com> wrote:
> > > * If the HTTP serialization thing is going to be a separate 
> > thing and 
> > > not built into the binding, it should be a feature (not a module, 
> > > since modules are specifically about SOAP) with its own 
> > URI.  Hence we 
> > > should add the following under the title of section 3.3:
> > 
> > But it isn't a feature, and it isn't a module.  Hugo labelled 
> > it as the HTTP serialization of the AD feature, which I'm 
> > comfortable with (much as I hate the term "serialization" 
> > with respect to XML).
> 
> I don't see any reason it shouldn't be a feature.  You yourself were

Because it isn't a feature.  It's a binding of a feature, a relationship
between a feature and a binding.

> talking about doing this kind of "adding features to bindings" many
> moons ago....  Making it a feature is a good thing because a) we have
> syntax to indicate it's required (see below), and b) someone could write
> a new HTTP binding which implemented that feature natively, and it would
> be clear what they meant.

Uh, no.  This particular writeup is specific to the feature and the
binding that it ties together.  Almost every such writeup will be.

> > > --
> > > This feature is identified with the URI 
> > > http://www.w3.org/@@@@/@@/features/AD-HTTP
> > 
> > So I'm doing this as "This feature-binding ...".  But where, 
> > if anywhere, would this URI be used?
> 
> If this is optional, and you're requiring it, you have to have a way of
> specifying that in WSDL, no?  That's why making it a feature is nice in
> that we can just say:
> 
> <binding type="http">
>   <feature uri="http://www.w3.org/@@@@/@@/features/AD-HTTP"
>            required="true"/>
>   ...
> </binding>
> 
> How else would you suggest we do this, since we're not making it a
> native part of the HTTP binding?

It seems obvious that if the AD feature is turned on, and the binding is
HTTP, that the HTTP AD feature binding must be used.  *shrug*

> > DONE with that modification.
> 
> ...pending resolution of these issues. :)

*shrug*  It isn't a feature.  A module isn't a feature, either, it's a
binding of a feature to SOAP.

Possibly a feature-binding needs a URI.  Possibly it's easiest and best at
this stage to use the feature element syntax to indicate that a
feature-binding is enabled for a particular binding.  But it *doesn't*
make the binding of a feature into a feature!  And confusion of the
language *won't* promote reader comprehension.

> > > --
> > > 
> > > * Sec 3.3.2, end of 2nd para, add "if possible" after "MUST 
> > be turned 
> > > into an HTTP header".
> > 
> > DONE.
> > 
> > Although that changes the meaning to, in effect, "MAY be 
> > turned into an HTTP header."  MUST is MUST; not fulfilling a 
> > MUST [MUST NOT] be permitted.  But then, we have a mandataory 
> > mandatoriness in part one, so why not?
> 
> This edit was because we say MUST and then have a bunch of "oh yeah and
> if this is true you just ignore this one" types of statements.  Thus
> it's MUST if possble.

*shrug*  So it's optional, under certain circumstances.  I think that "if
possible" may be read as an general escape hatch, rather than an
enumerated one.  It might be clearer to say "MUST with the exceptions
enumerated below".

> > > * Missed a couple of still-unquoted URIs
> > 
> > Argh.  I do not know where they are.  I don't see any.  Maybe 
> > you want quotes around some entity thingies?
> 
> Shouldn't references to the property name
> "http://www.w3.org/@@@@/@@/wsdl/feature/AD/data" be quoted?  See
> paragraph in 3.1.2.
> 
> Module name in first sentence of 3.2.
> 
> Feature URI in 3.2.1.
> 
> Property name in 3.2.2 (twice)
> 
> Feature URI in 3.3.1

Working.  I have to run an errand.  Hugo also pointed out that I've got an
abstract to update.  So, additional comments can be incorporated; I'll
expect to close the editing this afternoon.

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 30 July 2004 11:28:39 UTC