Requirements 4.1 General draft disposition

Per volunteering at
http://lists.w3.org/Archives/Member/w3c-ws-desc/2002Apr/0043.html
(members only), here are draft dispositions for the requirements in
section 4.1 that have not already been accepted or rejected;


R003

[Draft, Should, JS] Use available XML technologies wherever possible.

Proposal: Accept
Reason: Don't want to reinvent the wheel


R005

[Draft, Should, KL] Correct errors/inconsistencies in WSDL1.1

Proposal: Accept
Reason: Spec should not contain errors or be inconsistent.


R006

[Draft, Should, KL] Provide better specification for document name and
linking. WSDL1.1 section 2.1.1 is over simple. More detailed specification
should be provided to define how the import mechanism works, especially how
it's related to the import and include mechanism defined in the XML Schema
specification.

Proposal: Reword as 'Clarify the semantics of wsdl:include and wsdl:import'
Reason: It's the semantics that are currently underspecified. I suspect that
the clarification will be 'they work the way xsd:include and xsd:import
work', in which case I think that's enough.



R007

[Draft, Should, KL] Provide detailed examples including on-the-wire
Messages. (Was Best Practices and Conformance Test. Although a few examples
are given in WSDL 1.1 specification, the examples are not sufficiently
explained in the text, and no corresponding wired Message examples are
available for different InterfaceBinding definitions. To help clearer
interpretation of the specification, more consistent and detailed examples
should be provided. In addition, a technical report associated with the WSDL
specification should be dedicated to provide: Use cases which illustrate
typical usage scenarios of WSDL, Best practices, Conformance test suite.)

Proposal: Reject.
Reason: What messages look like is pretty much defined by either XML Schema
( or some other schema language ) or the SOAP Encoding rules. I'm not
against having examples in the spec, but I have no desire to reproduce
explanation which belongs in either the XML Schema Primer or the SOAP
Primer.


R009
[Draft, Should, KL] Enable easy Interaction with Upper layers in the Web
Services stack. Additional technologies will be required in the future to
complete the Web Services architecture. As one of the fundamental layers of
the Web Services stack, though WSDL should not depend on any other layers,
one of the design goals of WSDL should be easy interaction with upper
layers, such as Services composition layers.

Proposal: Reject.
Reason: I'm not convinced that the 'upper layers' are known, defined or
understood at this point. We are using XML. XML is extensible. The burden
lies with anyone defining a higher layer, and wanted to 'aggregate' or
otherwise build on WSDL. If they can't figure out how to interact
with/extend our spec then they're in the wrong job. I'm also unconvinced as
to how we would measure our success regarding this requirement.


R010
[Draft, Should, KL] Editorial Improvements. Consistent terminology should be
used across all the sections of the specification. As one example, the usage
of the terms 'port' and 'endpoint' is confusing to many readers. Though it
states that 'port' is 'a single endpoint defined as a combination of a
binding and a network address', the specification uses 'port' and 'endpoint'
interchangeably in many places. Some diagrams that explain the structure of
core WSDL elements and their relationship will help reduce
misinterpretations.

Proposal: Trim to 'Consistent terminology should be used across all the
sections of the specification.' and accept
Reason: Consistency is good.


R103
[Draft, Should, YF] WSDL specifications should be clear and easy to
understand. This clarity implies that considerable editorial effort will be
required in the structuring of the narrative through both outline/overview
and normative reference material.

Proposal: Reject.
Reason: A specification should be precise. Clear and easy to understand are
both very subjective ( and to my mind, of secondary importance to
precision ). I don't think anyone intends to make the spec unnecessarily
baroque.


R105
[Draft, Should, YF] The WSD specification should make reasonable efforts to
support applications that operate on resource constrained devices. Even
though any practical device is resource constrained in any number of
dimensions including but not limited to bandwidth, computational power and
storage, the term 'resource constrained device' often refers to
hand-portable devices. This document does not attempt to define the term
'resource constrained' nor what the constraints are for the available
resources.

Proposal: Reject.
Reason: Requirement says nothing concrete.


Hope this helps,

Gudge

Received on Saturday, 20 July 2002 10:32:30 UTC