Re: [wsrp-wsia] [change request #143] Properly encode '&' in examplesand BNF

[Alejandro Abdelnur <alejandro.abdelnur@sun.com>]

I don't get it, are you saying that the consumer rewriting happens 
before the you get the content from the WS stack? That's odd.

Doing a step by step I don't see a problem:

A portlet creates content using XML escaping rules only if it wants to 
use a special XML character (<, >, &) and it wants it to be displayed 
[instead of being intepreted as XML special character] by the user 
agent. If the stack needs to encode this to send it over the wire 
(producer to consumer), the stack will decode it.

The portlet creates the following content:

<B>Hello, <A 
HREF="wsrp-rewrite?wsrp-urlType=action&message=greetings/wsrp-rewrite">click 
here!</A></ B>

The producer WS stack XML escapes it:

&lt;B&gt;Hello, &lt;A 
HREF="wsrp-rewrite?wsrp-urlType=action&amp;message=greetings/wsrp-rewrite"&gt;click 
here!&lt;/A&gt;&lt;/ B&gt;

The producer sends the content to the consumer. The consumer WS stack 
decodes it back to what the portlet originally created. The consumer 
looks for templates to rewrite 'wsrp-rewrite? .... /wsrp-rewrite', and 
replaces the template with a well formed URL:

<B>Hello, <A 
HREF="http://foo.com?target=myPorltet&wsrp-urlType=action&message=greetings";>click 
here!</A></ B>

Consumer creates portal page with this content and sends it back to 
user-agent without further escaping/encoding.

The portlet is responsible for doing URL escaping (using the %HH) for 
characters that have special meaning r are not valid in the querystring. 
For example, if you want the user agent and the server receiving the 
request to see & as a regular character instead interpreting it as a 
name/value separator you use %26 instead &.  But this is not affected by 
the XML encoding done by the WS stack.

On the way back the URL is processed correctly by the consumer and it 
may undergo an XML encoding when going from consumer to producer but 
this is done by the WS stack.

Alejandro


Michael Freedman wrote:

> What you are missing is the difference between what is transported 
> over the wire and what the consumer/client sees.  Yes, the & is 
> transformed by the underlying stack to &amp; to carry in the soap 
> message -- however on the other side the consumer/client sees the 
> value as merely &. Though we could claim that consumer rewriting 
> occurs before other processing and hence could replace the & with an 
> &amp; what do we do in the template case?   Once we account for &amp; 
> in producer templates shouldn't we be consistent with consumer 
> rewriting?  Finally note, though I suggested we merely require &amp; 
> use rather then both we will need to think this through carefully.  
> There is a [slight] performance impact on supporting both but we need 
> to ensure that &amp; is valid for all document types/browsers whether 
> the document type be XML based/related or not.  If we can't convince 
> ourselves of this then we will probably need to support both forms -- 
> the semantics are easy for the consumer -- merely pass on what you 
> receive [assume the producer did the right thing].  Producer templates 
> however get ugly at it would seem we would need to pass an XML 
> friendly form and regular form doubling the number of templates we carry.
>       -Mike-
>
> Alejandro Abdelnur wrote:
>
>> Wouldn't this be taken care by the XML encoding that happens when you 
>> put the content into the SOAP response? Same as the < and > ? What am 
>> I missing?
>>
>> Rich Thompson wrote:
>>
>>> Document: Spec
>>> Section:  10.2.1 and 10.2.2
>>> Page/Line: 58/15 and 61/24
>>> Requested by: Mike Freedman
>>> Old text: 
>>> wsrp-rewrite?wsrp-urlType=value&name1=value1&name2=value2.../wsrp-rewrite 
>>>
>>>
>>> New text: wsrp-rewrite?wsrp-urlType&amp;name1=value1&amp;name2=value2
>>> .../wsrp-rewrite
>>>
>>> Reasoning: If the content containing the wsrp-rewrite is XML them 
>>> the use of & makes its on invalid document.  Rather the & must be 
>>> expressed as &amp;  We should just make this form the standard use 
>>> rather then supporting both flavors as supporting both has a 
>>> negative impact on the implementation/performance of the consumer 
>>> rewrite code -- something that needs to stay as efficient as 
>>> possible.  Note: we should also change the producer template URL to 
>>> use &amp; as we don't know the content the producer will produce.  
>>> Finally, we should chaneg the BNF. FYI ... what follows is a brief 
>>> paragraph from the XHTML spec explaining the above problem:
>>>
>>> C.12. Using Ampersands in Attribute Values (and Elsewhere)
>>> In both SGML and XML, the ampersand character ("&") declares the 
>>> beginning of an entity reference (e.g., &reg; for the registered 
>>> trademark symbol "®"). Unfortunately, many HTML user agents have 
>>> silently ignored incorrect usage of the ampersand character in HTML 
>>> documents - treating ampersands that do not look like entity 
>>> references as literal ampersands. XML-based user agents will not 
>>> tolerate this incorrect usage, and any document that uses an 
>>> ampersand incorrectly will not be "valid", and consequently will not 
>>> conform to this specification. In order to ensure that documents are 
>>> compatible with historical HTML user agents and XML-based user 
>>> agents, ampersands used in a document that are to be treated as 
>>> literal characters must be expressed themselves as an entity 
>>> reference (e.g. "&amp;"). For example, when the href attribute of 
>>> the a element refers to a CGI script that takes parameters, it must 
>>> be expressed as 
>>> http://my.site.dom/cgi-bin/myscript.pl?class=guest&amp;name=user 
>>> rather than as 
>>> http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user.
>>>
>>>
>>>
>>>
>>> ----------------------------------------------------------------
>>> 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>
>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>