W3C home > Mailing lists > Public > public-ws-semann@w3.org > November 2006

Re: [Fwd: WSDL WG Last Call comments on SAWSDL]

From: Joel Farrell <joelf@us.ibm.com>
Date: Thu, 2 Nov 2006 16:24:20 -0500
To: SAWSDL public list <public-ws-semann@w3.org>
Message-ID: <OFB2FAD7FD.C17776CA-ON8525721A.00756809-8525721A.007595C7@us.ibm.com>
Hello All,

These changes are the resolution to LC Issue 1 and have been documented in
the latest editors' draft -
http://www.w3.org/2002/ws/sawsdl/spec/SAWSDL.html.

Regards,
Joel

public-ws-semann-request@w3.org wrote on 10/31/2006 10:16:20 AM:

>
> Hi editors,
> here's a suggested wording for fixing these editorial issues:
>
> On Tue, 2006-10-24 at 17:53 +0200, Jacek Kopecky wrote:
> > -------- Forwarded Message --------
> > "In terms of the WSDL 2.0 component model, a model reference is a new
> > property. In particular, when used on an element that represents a WSDL
2.0
> > Component (e.g. wsdl:interface, wsdl:operation, top-level xsd:element,
> > etc.), the modelReference extension attribute introduces an OPTIONAL
> > property {model reference} whose value is a set of URIs taken fromthe
value
> > of the attribute. The absence of the {model reference} property is
equal to
> > its presence with an empty value."
> >
> > 1) Editorially, it would be nice to refer to WSDL 2.0 Components by
name
> > instead of by their corresponding element.  Esp. in the case of xsd:*,
there
> > is both a WSDL component and a Schema component, so by naming an xsd
element
> > it's not clear which component one might be referring to (the context
makes
> > it clear in this case, but still, we invented names for components, you
> > might as well use them!)  The same style can also apply to the last
> > paragraph of section 2.2.
>
> Change the paragraph in 2.1 starting with "In terms of the WSDL 2.0
> component model" to
>
> <p>In terms of the WSDL 2.0 component model, a model reference is a new
> property. In particular, when used on an element that represents a WSDL
> 2.0 Component (e.g. a <code>wsdl:interface</code> element representing
> an <a href="http://www.w3.org/TR/wsdl20/#Interface">Interface</a>
> component, a <code>wsdl:operation</code> element representing an <a
> href="http://www.w3.org/TR/wsdl20/#InterfaceOperation">Interface
> Operation</a> component, or a top-level <code>xsd:element</code>
> representing an <a
> href="http://www.w3.org/TR/wsdl20/#component-ElementDeclaration">Element
> Declaration</a> component, etc.), the <em>modelReference</em> extension
> attribute (with a non-empty value) introduces an OPTIONAL property
> {model reference} whose value is the non-empty set of URIs taken from
> the value of the attribute. An empty model reference or no model
> reference are both reflected by the absence of the {model reference}
> property on the given component.</p>
>
> Similarly, change the last para of 2.2 (starting with "When used on")
> to:
>
> <p>When used on an element that represents a WSDL 2.0 Component (a
> top-level <code>xsd:element</code> element representing an <a
> href="http://www.w3.org/TR/wsdl20/#component-ElementDeclaration">Element
> Declaration</a> component, an <code>xsd:complexType</code> element or an
> <code>xsd:simpleType</code> element representing a <a
> href="http://www.w3.org/TR/wsdl20/#component-TypeDefinition">Type
> Definition</a> component), the loweringSchemaMapping and
> liftingSchemaMapping extension attributes introduce OPTIONAL properties
> {lowering schema mapping} and {lifting schema mapping}. The value of
> either of these properties is a (possibly empty) set of URIs taken from
> the value of the respective attribute. In contrast to the {model
> reference} property, the absence of the {lifting schema mapping} and
> {lowering schema mapping} properties <em>is different from</em> its
> presence with an empty value, as mappings on an element must be able to
> override the mappings specified on the type of the element.</p>
>
> > 2) Secondly, there are two ways to interpret the last sentence.
Presumably,
> > an empty attribute would result in the presence of an empty {model
> > reference} property, which would be _semantically_ equivalent to no
{model
> > reference} property.   However, it might also be interpreted that in
this
> > situation the property could simply be omitted from the component
model.  We
> > had some similar text in places in WSDL that gave us a bit of a
headache in
> > the interchange format, which requires a canonical component model.
> > Basically, two processors that are both SAWSDL aware might have
different
> > component models - one might omit {model reference} and one might
include it
> > with an empty value.  This could be dealt with in the comparison
algorithm
> > between two component models, but we've found it easier to just define
a
> > single clear mapping from XML to the component model.  In this case,
for
> > instance, you could state "when non-empty and used on an element..."
and
> > simply omit the last sentence, or you could state "The absence of the
{model
> > reference} property is semantically equivalent to its presence with an
empty
> > value."  The former seems cleaner to me as it doesn't augment the
component
> > model with meaningless information.
>
> done above, dropped {model reference} in case it'd be empty
>
> > 3) Along the lines of (1), it would be nice to be explicit about the
> > components being annotated with properties in section 2.1.x.
>
> I'd suggest adding these small paragraphs to the ends of the 2.1.x
> sections:
>
> 2.1.1:
>
> A non-empty modelReference on a WSDL interface is represented as {model
> reference} property of the Interface component; the case of an empty
> modelReference or no modelReference at all is represented with an
> Interface component that does not have a {model reference} property.
>
> 2.1.2:
>
> A non-empty modelReference on a WSDL interface operation is represented
> as {model reference} property of the Interface Operation component; the
> case of an empty modelReference or no modelReference at all is
> represented with an Interface Operation component that does not have a
> {model reference} property.
>
> 2.1.3:
>
> A non-empty modelReference on a WSDL interface fault is represented as
> {model reference} property of the Interface Fault component; the case of
> an empty modelReference or no modelReference at all is represented with
> an Interface Fault component that does not have a {model reference}
> property.
>
> 2.1.4:
>
> A non-empty modelReference on a top-level simple type used in WSDL is
> represented as {model reference} property of the Type Definition
> component; the case of an empty modelReference or no modelReference at
> all is represented with a Type Definition component that does not have a
> {model reference} property.
>
> 2.1.5:
>
> A non-empty modelReference on a top-level complex type used in WSDL is
> represented as {model reference} property of the Type Definition
> component; the case of an empty modelReference or no modelReference at
> all is represented with a Type Definition component that does not have a
> {model reference} property.
>
> 2.1.6:
>
> A non-empty modelReference on a top-level element declaration used in
> WSDL is represented as {model reference} property of the Element
> Declaration component; the case of an empty modelReference or no
> modelReference at all is represented with a Element Declaration
> component that does not have a {model reference} property.
>
> 2.1.7:
>
> A non-empty modelReference on a top-level attribute declaration used in
> WSDL is represented as {model reference} property of the Attribute
> Declaration component; the case of an empty modelReference or no
> modelReference at all is represented with a Attribute Declaration
> component that does not have a {model reference} property.
>
>
>
> Finally, when we talk about WSDL components (e.g. in 2.1.1 1st para) we
> should use the official names, i.e. not italic "interface", but
> "Interface", or just talk about the elements. Similarly, WSDL
> distinguishes Interface Operation components and Binding Operation
> components, even though the elements in XML have the same name.
>
> Hope this helps,
>
> Jacek
>
>
Received on Thursday, 2 November 2006 21:24:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:46 UTC