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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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


Subject: RE: [wsrp] URL rewriting expression required to be valid for its mime type?


For (2) the fragment will still not be a well-formed XML document. It will claim to be "xml+" but will fail to start with "<?xml".
 
One possibility would be to add a new mime type parameter e.g. "text/xml+...; fragment=true"
(XML friendly with "&amp;"s or "text/xml+..; requiresRewrite=true" (using "&"s presumably) ,
but I just wanted to point out that 2 and 3 are somewhat questionable (and 1 is really up to the
producer to solve internally).
 
I still agree that requiring consumers to both support & and &amp; is a useful.
 
thanks,
Andre
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 12 June 2003 20:01
To: wsrp@lists.oasis-open.org
Subject: [wsrp] URL rewriting expression required to be valid for its mime type?


I was asked to start this thread for enumerating the issues and how the proposed solution addresses them.

Basic issue is that the format of our URL rewriting expression (wsrp-rewrite?wsrp-urlType=value&name1=value1.../wsrp-rewrite) is not valid for XML markup types. In particular, XML requires that the character "&" be represented as the entity "&amp;". We should note that the values a portlet author could write into the expression potentially also suffer from this problem. This problem becomes acute when one considers the impacts on various parties:
  1. Portlet author: At least one technology (serialization of a DOM) can not be used to produce invalid XML. Others may also impose this requirement of producing a valid output stream.
  2. Intermediaries: When the markup moves out into an attachment, it will be natural for an intermediary to examine the fragment. This examination will fail if the fragment is invalid for its mime type.
  3. Consumer processing: For some Consumer implementations, it would be required that the URL rewriting take place very early in the processing of the fragment in order to make the fragment valid for other steps to process.

The proposed solution is to require Consumers to accept both "&" and "&amp;" as the name/value pair separator. We would also encourage portlet authors to use the entity approach for ease of upgrading when their content gets placed into an XML markup type.

Andre's quick test suggested that even when such an entity reference makes it to the browser the browser tends to parse the entity reference and replace it with the represented character such that no special code should be required of the Consumer when processing an activated URL that had contained an entity reference.

I would note that this solution does not address whether or not the values written into the URL are valid for the mime type. I will plan to look again at the wording, but suggest that the requirement for strict encoding of values placed in URLs point out that the encoding needs to take into account both the fact that the value is being placed into an URL and that the URL will be in a document of a particular mime type. As a result, the encoding needs to deal with any characters special to URLs and/or the mime type.

Rich Thompson


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