[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [change request #143] Properly encode '&' in exam plesand BNF
We have the MarkupContext.markupType to guide us (which may state some XML based doc type) but I would only consider this valid at the consumer after: the Web stack has deserialized the markupString (converting & back to & etc. following entity encoding rules applied to xsd:string); the consumer has applied the URL re-writing algorithm; the markup fragment has been converted/included to an XML document. [Similar processing for markupBinary or (future) attachments.] Therefore we do not need to be XML compliant at the consumer re-write step? Producer templates have no "&", so no problems there either. regards, Andre -----Original Message----- From: Michael Freedman [mailto:Michael.Freedman@oracle.com] Sent: 13 February 2003 23:53 To: wsrp-wsia Subject: Re: [wsrp-wsia] [change request #143] Properly encode '&' in examples and BNF Yep, that's much better teno-speak then I wrote. Sorry for the confusion. -Mike- Alejandro Abdelnur wrote: > I think I've got it, you are saying that "Query Strings in well formed > documents must use & to separate name/value pairs, the use of & is > not correct and it may break some XML clients". Correct? > > Michael Freedman wrote: > >> 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: >>> >>> <B>Hello, <A >>> HREF="wsrp-rewrite?wsrp-urlType=action&message=greetings/wsrp-rewrite"&g t;click >>> here!</A></ B> >>> >>> 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 & 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 & what do we do in the template case? Once we account for >>>> & in producer templates shouldn't we be consistent with >>>> consumer rewriting? Finally note, though I suggested we merely >>>> require & 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 & 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&name1=value1&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 & 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 & 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., ® 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. "&"). 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&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> >>> >>> >>> >>> >>> >> >> >> >> ---------------------------------------------------------------- >> 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