wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [wsrp] URL rewriting expression required to be valid for its mime type?
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Thu, 12 Jun 2003 15:00:57 -0400
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 "&".
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 "&" 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]