RE: Edits to part 2

Hi Amy!

> 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
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 
> > 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?

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

> > * 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 
> > 
> (http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?c
> > 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
"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



Thanks, Amy.

--Glen

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