Re: Requirements 4.1 General draft disposition

Simon Fell has reminded me that WSDL does not have an include element (
R006 ). So the requirement becomes 'clarify the semantics of wsdl:import'.
My gut feel is that XInclude would be suitable for real inclusions but
Jonathan probably has a more accurate take on that.

Gudge

----- Original Message -----
From: "Martin Gudgin" <marting@develop.com>
To: <www-ws-desc@w3.org>
Sent: Wednesday, April 10, 2002 4:10 PM
Subject: 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 Thursday, 11 April 2002 03:29:00 UTC