RE: Edits to part 2

Hi Amy!

> On Thu, 29 Jul 2004 18:10:05 -0400
> Glen Daniels <> 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
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.

> > --
> > This feature is identified with the URI 
> >
> 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=""

How else would you suggest we do this, since we're not making it a
native part of the HTTP binding?

> DONE with that modification.

...pending resolution of these issues. :)

> > --
> > 
> > * Sec 3.3.2, end of 2nd para, add "if possible" after "MUST 
> be turned 
> > into an HTTP header".
> 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.

> > * Sec 3.3.2, first para after the bullet list, add 
> "property " before 
> > "<constraint>" to make this more clear and avoid confusion 
> like Hugo 
> > had.
> DONE.  I don't like the result, though.  Should it be tagged, 
> instead, so that it shows up like {property constraint}?

If we refer to it that way elsewhere, then sure.

> > * Fix the link in that same sentence to point to the property 
> > constraint description in part 1 
> > 
> (
> > on
> > tent-type=text/html;%20charset=utf-8#Property)
> Errm.  I don't know how to do this, or if it can be done.  
> That link is generated by a bibref tag, with the attribute 
> ref="WSDL-PART1".  Can I put #Property at the end of the 
> attribute value?  Or do I need to do something #else?  Or is 
> it not doable?  Or xspecref instead?

Can't help you there... :(

> > * 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
"" 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

Thanks, Amy.


Received on Friday, 30 July 2004 11:10:58 UTC