The problem is getting each side to know what the other side needs/does as both need to coordinate. -Mike-

Eilon Reshef wrote:

Mike,

Isn't that something that's complete up to the Consumer, i.e., if the Consumer writes the links then it's transparent to the protocol and if the Producer writes the links then it's up to the Consumer to pass & if it so wishes?

Eilon

-----Original Message----- From: Michael Freedman [mailto:Mich...@oracle.com] Sent: Thursday, February 13, 2003 5:00 PM To: wsrp-wsia Subject: Re: [wsrp-wsia] [change request #143] Properly encode '&' in examples and BNF

What if the content being returned to the consumer is an XML document that contains the link in your sample? Won't the resulting XML document be invalid -- i.e. things would fail if/when you ran an XML processor over it -- for example to apply a stylesheet? I.e. in your example if the consumer/user-agent treats the markup you show as an XML document vs. an HTML document then the content is invalid because you haven't used & vs. the &. -Mike-

Alejandro Abdelnur wrote:

> 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="[1]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 "(R)"). 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 >>>> [2]http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user >>>> rather than as >>>> [3]http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user. >>>> >>>> >>>> >>>> >>>> ---------------------------------------------------------------- >>>> To subscribe or unsubscribe from this elist use the subscription >>>> manager: <[4]http://lists.oasis-open.org/ob/adm.pl> >>>> >>>> >>> >>> >>> >>> ---------------------------------------------------------------- >>> To subscribe or unsubscribe from this elist use the subscription >>> manager: <[5]http://lists.oasis-open.org/ob/adm.pl> >> >> >> >> >> >> >> ---------------------------------------------------------------- >> To subscribe or unsubscribe from this elist use the subscription >> manager: <[6]http://lists.oasis-open.org/ob/adm.pl> > > >

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

References

Visible links 1. http://foo.com/?target=myPorltet&wsrp-urlType=action&message=greetings 2. http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user 3. http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user 4. http://lists.oasis-open.org/ob/adm.pl 5. http://lists.oasis-open.org/ob/adm.pl 6. http://lists.oasis-open.org/ob/adm.pl 7. http://lists.oasis-open.org/ob/adm.pl