RE: [wsrp] Should URL rewrite expressions be required to be valid for the mime type?

[Andre Kramer <andre.kramer@eu.citrix.com>]

I still need some real convincing that this is a problem, as URLs are very likely to be attributes or strings (quoted values in script) or that CDATA sections can be used. Can anyone show me an instance of a re-write expression being carried in an XML element's content? Otherwise, why not just say that consumer re-writes are strings (e.g. only for XHTML attributes and not for element data)?

 

However, we could look to add an XML friendly way to represent re-writes. This would be structured to allow for easy XML processing (rather than something query string - like for humans to type):

 

<rewrite xmlns="urn:oasis:names:tc:wsrp:v2.0" type="blockingAction">

    <interactionState>submitOrders</interactionState>

</rewrite>

 

regards,

Andre

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 05 June 2003 18:59
To: wsrp@lists.oasis-open.org
Subject: [wsrp] Should URL rewrite expressions be required to be valid for the mime type?

This is the question raised about our rewrite expression format. The basic issue is that for XML mime types, it is inherently invalid as the '&' will be interpreted as the beginning of an XML entity reference. Three basic resolutions have been proposed:

1. Leave as is: This allows people's current implementations to remain as is. The downside is that XML intermediaries will be unable to deal with out fragments even when they move out into attached documents. It also means that implementations which build a DOM and then use the DOM serialization to write out the markup can not use Consumer URL rewriting as the serializer will not put out invalid markup.

2. Switch the '&' character to another (e.g. '$'): This deals with the immediate problem without having to address the larger issue of characters within the portlet URL parameter's value.

3. Require that the URL expression be properly encoded for the markup's mime type: This completely solves the problem, but introduces an additional step at the Producer to do this encoding and a mime type dependent decoding on the Consumer.

As commented on in today's call, both comments on these solutions and the proposal of additional solutions are welcome. We will look to resolve this issue on the 6/11 TC call.

Rich Thompson