OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [wsrp-wsia] [I#179] requestParameter semantics unclear


I realize some of us may care about ASP as well, but the protocol should
not.

I believe the proposal I sketched to replace the (rather unclear)
requestParameters covers all the Web technologies but may require work on
either the consumer or producer to break out POSTed files:


<!-- queryParameters carry URL query string or GET form contents -->
<element name="queryParameter" type="types:NamedString" minOccurs="0"
maxOccurs="unbounded"/> 

<!-- formParameters carry POSTed strings values for form input strings. Used
for application/x-www-form-urlencoded POSTs and for multipart/form-data if
the POST input has been de-constructed (together with zero or more
UploadContexts). -->
<element name="formParameter" type="types:NamedString" minOccurs="0"
maxOccurs="unbounded"/>

<!-- the consumer MUST filter out any query or post content that it caused
to be added to the request
(e.g. extra hidden input fields or field name modifications for markup
namespacing or scripting purposed).
WSRP URL parts (i.e. wsdl-*) are not included as parameters.
For POSTs, the producer can not rely on it's action URL query parameters
being returned.
Since both queryParameters and formParameters are minOccurs="0" we waste no
bandwidth.
-->

<!-- UploadContexts carry binary (MIME) inputs
The input may be available as one binary input (e.g. a http POST) or
as separate MIME objects (e.g. if consumer has broken up a
multipart/form-data POST
but not if only one UploadContext of type multipart/form-data is supplied)
or (optionally) as both.
If both are provided one (and only one) of the UploalContexts has the
"input" attribute set to true.
-->
<complexType name="UploadContext">
  <sequence>
     <element name="mimeType"    type="xsd:string"/>
     <element name="uploadData"  type="xsd:base64Binary"/>
     <element name="mimeHeaders" type="types:NamedString" minOccurs="0"
maxOccurs="unbounded"/>
     <element name="extensions"  type="types:Extension"   minOccurs="0"
maxOccurs="unbounded"/> 
  </sequence>
  <attribute name="input" type="xsd:boolean" use="optional"
default="false"/>
</complexType>
<element name="uploadContext" type="types:UploadContext" minOccurs="0"
maxOccurs="unbounded"/>


An alternative would be to specify a logical form and request input model
(i.e. no GETs: performInteractions stands for "POST Every Request FORM
Interaction") and limit our protocol to this abstracted model, which, in
some sense, is what we had with "requestParameters" and only one
UploadContext?

regards,
Andre

-----Original Message-----
From: Eilon Reshef [mailto:eilon.reshef@webcollage.com]
Sent: 11 December 2002 21:55
To: Andre Kramer; wsrp-wsia@lists.oasis-open.org
Cc: david.ward@oracle.com
Subject: RE: [wsrp-wsia] [I#179] requestParameter semantics unclear


I am not sure I agree with the statement below (in boldface). I think ASP is
different, but in any case I think we should care.
-----Original Message-----
From: Andre Kramer [mailto:andre.kramer@eu.citrix.com] 
Sent: Wednesday, December 11, 2002 7:58 AM
To: wsrp-wsia@lists.oasis-open.org
Cc: 'david.ward@oracle.com'
Subject: RE: [wsrp-wsia] [I#179] requestParameter semantics unclear


Also, ASP may differ from ASP.NET but we don't care. 
regards, 
Andre 
-----Original Message----- 
From: Rich Thompson [mailto:richt2@us.ibm.com] 
Sent: 10 December 2002 19:31 
To: wsrp-wsia@lists.oasis-open.org 
Subject: Re: [wsrp-wsia] [I#179] requestParameter semantics unclear 







Current spec language: 
  requestParameters: Name/value pairs reflected from the query string of 
  the activated URL. These are the query string parameters the Consumer did 
  not consume by processing them itself. Other name value pairs (e.g. HTTP 
  headers from the client or additional Consumer-supplied data) should be 
  placed in the extensions array. 
This certainly covers the first 2 (action URLs and method=get both use 
query strings). We may want to expand it to include the third as well. 
Could not a .Net Producer just supply the same values for both APIs? 
Rich Thompson 


                      Gil Tayar 
                      <Gil.Tayar@webcol        To: 
wsrp-wsia@lists.oasis-open.org                                  
                      lage.com>                cc: 
                                               Subject:  [wsrp-wsia] [I#179]

requestParameter semantics unclear          
                      12/10/2002 03:18 
                      AM 




Issue: 179 
Status: Active 
Topic: interface 
Class: Minor_Editorial 
Raised by: Eilon Reshef 
Title: requestParameter semantics unclear 
Date Added: 10-Dec-2002 
Document Section:   v0.85/5.1.6 
Description: 
"requestParameters: I am not sure what the intent of this variable is. 
it can mean three different things: 
1. Data items passed as part of the action URL - this seems redundant as 
the Producer can easily use navigationalState. 
2. Data items passed as <form method=get> submit? Is this indeed the case? 
3. Data items passed as <form method-post> submit? Is this indeed the case? 
Note that (2) and (3) are accessed using the same API in J2EE but not in 
ASP, so if the intent is also for (2) and (3) then we may need to 
differentiate." 



---------------------------------------------------------------- 
To subscribe or unsubscribe from this elist use the subscription 
manager: <http://lists.oasis-open.org/ob/adm.pl> 
---------------------------------------------------------------- 
To subscribe or unsubscribe from this elist use the subscription 
manager: <http://lists.oasis-open.org/ob/adm.pl> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC