Re: WSDL 1.2: Updated draft (June 30) - typos and minor errors

"Jean-Jacques Moreau" <moreau@crf.canon.fr> writes:
>
> Kevin, thanks for pointing these out. I've have left the most
controversial
> ones, done the others.

Thanks from me too Kevin!

> > >>>Section 2 (text above the box for "issue-require-targetnamspace")
the
> > new text for targetNamespace is not very clean - maybe just for me. I
> > believe the resolution is to make defintion@targetNamespace required.
All
> > children elements defined by this wsdl document belongs to this
namespace. I
> > know we are talking about abstract model here, but if map to the wsdl
> > elements, the wording reads like wsdl1.2 requires that every individual
> > child elements, except type element,  have a targetNamespace attribute.
I
> > don't believe that's what we meant.
> >
> > Again, this may be just my own interpretation, other people may
interpret
> > differently. To avoid future confusion,  can we make the wording more
> > straight-forward?
>
> I think you're right, this needs rewording. NOT done.

I changed the relevant paragraphs as follows:

==========
<p>A definitions group has a REQUIRED "targetNamespace" property
identifying the namespace in which all description components
contained within it will be defined. This property SHALL NOT apply to
the type description component as type definition languages are
assumed to have their own mechanism for this purpose.</p>

<issue id="issue-require-targetnamespace" status="closed">
  <head>Require targetNamespace attribute?</head>
  <source>Sanjiva Weerawarana</source>
  <p>WSDL 1.1 indicates that the targetNamespace attribute is
  optional. I would like to make it required as otherwise
  the NCNames used in other places don't make much sense.</p>
  <resolution><p>Accepted during telecon on June 27, 2002.</p></resolution>
</issue>

<p>Every description component, except type description components,
has a REQUIRED "name" property. The value of this property combined
with the value of the targetNamespace property of the containing
description group forms a qualified name (QName) which MUST uniquely
identify the definition component from amongst all other description
components of the same kind. That is, each kind of description
component has its own <emph>symbol space</emph>. For example, it MAY
be the case that the value of the "name" property of a portType
description component and that of a serviceType description component
belonging to the same targetNamspace, are the same.</p>
==========

Thanks to Jean-Jacques for fixing all the other bugs that Kevin
pointed out.

Bye,

Sanjiva.

Received on Thursday, 4 July 2002 10:19:37 UTC