Re: WSDL, parameter typing, and forms

At 10:43 PM 2002-06-24, Mark Baker wrote:

>On Mon, Jun 24, 2002 at 11:55:57AM -0700, David Orchard wrote:
>> One of the interesting places this might lead us, is that if we think that
>> there should be typing available for the GET query string, I'm not sure that
>> it's a WSD problem.  Seems like mapping Schema to url-encoded nvp is more
>> general than wsd.
>
>IMO, this is most definitely a WSDL problem.  HTML forms are currently
>more capable than WSDL here; they have a type system[1], and a means to
>bind those types to field names.

And XForms refines this.

>I don't think it's appropriate to put type information in the URI
>because the URI is opaque to the client.  

The service offering, in the accessibility architecture envisioned in

 some WAI comments on Device Independence
 http://lists.w3.org/Archives/Public/www-archive/2001Nov/0069.html

is not type-unconstrained, nor the user+client type-unaware in acting to 
selectively issue service requests.

In HTTP today this can be expressed in the Accept: header.

In the above sketch, where some of the available service forms are subject to
sensory-mode dependencies (such as video or audio streams) there are multiple
service options disclosed to the client as equivalents by some mechanism not 
unlike OBJECT in HTML or SWITCH in SMIL.  Sometimes these will be given different
URIs by the server(s), and sometimes the equivalence group will be served under
one URI and discriminated only by type.

The user or their agent software running on the client node (the server and 
the server protocol don't know which) elects an option and issues a service 
request in which the type information used in the OBJECT or SWITCH 
discrimination process would reasonably be a binding constraint on the terms 
of service.

 From a service-flow perspective, the primitive is the service request,
not just the key provided in HTTP by the Location: header.  Even in the special
case of current HTTP negotiation, the Accept: header is part and parcel of the 
request.  

The service negotiation protocol envisioned for people with disabilities 
includes that the user has the option to review and approve the actual 
instances of service offered as substitutable options; although before
this level of control is entered if there is type knowledge of the user's
preferences this type knowledge will be automatically applied in service
adjustments negotiated between the user's agent and the server before the
user sees any instances.  And in the absence of type preferences known to
the user's agent, the server will follow preferences over the options
established by the [service sponsor a.k.a. content manager a.k.a. business 
entity behind the Web server per_se].

Types are expected to be useful and used in the negotiation of detailed terms 
of service to achieve disability-adaptive refinement or adjustment in 
service-delivery chains.

 Discovery Plus
 http://trace.wisc.edu/docs/ud4grid/#_Toc495220392

Regardless of whether the type constraint information in the service request
is encoded as HTTP:Accepts: headers, CC/PP, or URI choice under WSDL guidance,
please do not assume that clients are type-unaware and just acting on
type-opaque service offerings from servers.  This will break the emerging
strategy for offering alternative modes of service as required to serve
people with disabilities.

Contrary to what Len Bullard said earlier, the upper layers are not un-architectural.

There is an aspect of Web operation that could be termed "type abstraction, refinement
and enforcement."  The health of the vertical integration, across all layers or tiers
of service, of this aspect of Web operation is an architectural trait.  At least our [WAI] 
vision for an accessible-by-construction Web exposes a dependency on this trait, so we hope 
W3C/TAG will claim this trait as an architectural concern.

Al

>If the client is constructing
>a URI, it should only be because the server told it how, with a form.
>And in that case, the server already knows the types.
>
> [1] http://www.w3.org/TR/html401/sgml/dtd.html#InputType
>
>MB
>-- 
>Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
>Ottawa, Ontario, CANADA.               distobj@acm.org
>http://www.markbaker.ca       http://www.idokorro.com

Received on Tuesday, 25 June 2002 10:18:31 UTC