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] Should URL rewrite expressions be required to be valid for themime type?



This proposal is the equivalent of saying that the rewrite expression should be valid for the document's mime type, but isn't required to be. I could see requiring Consumers to always support both '&' and "&" as separators, but would then require Producers to use "&" when outputting XML (i.e. output valid XML). This has the advantages that content authors can always use "&" if they prefer to ignore the mime type (e.g. embeddable static sub-fragments), allows for XML intermediaries and provides well-defined Consumer parsing rules.

Rich Thompson



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

06/09/2003 08:41 AM

       
        To:        "'David Ward'" <david.ward@oracle.com>, Andre Kramer <andre.kramer@eu.citrix.com>
        cc:        wsrp@lists.oasis-open.org
        Subject:        RE: [wsrp] Should URL rewrite expressions be required to be valid         for the mime type?



I see my confusion now: I'm already allowing both "&" and "&amp;" as a separator in wsrp consumer re-write strings! This is quite possible as the pattern is always: a "&"; then zero or more chars; then "wsrp-"; followed by the token specific name that requires re-writing. Therefore the content writer (author / developer or tool) can write either:
 
<a href="wsrp-rewrite?wsrp-urlType=blockingAction&wsrp-interactionState=xxx/wsrp-rewrite"/>
<a href="wsrp-rewrite?wsrp-urlType=blockingAction&amp;wsrp-interactionState=xxx/wsrp-rewrite"/>
 
Or even use a mix of "&" and "&amp;". I realize the spec uses only "&" but I thought the proposal was to use "&" or "&amp;" depending on whether or not the context was XML or non-XML, not relaxing the implementation to cope with attribute strings!
 
So, how about the following proposal:
 
Both "&" and "&amp;" are allowed in consumer re-write expression as separators. Content authors are encouraged to use "&amp;" in XML. Is that not how URLs in HTML/XHTML are handles today?
 
Then the issue of an XML friendly way to represent re-write expressions is a secondary one ...
 
regards,
Andre
-----Original Message-----
From:
David Ward [mailto:david.ward@oracle.com]
Sent:
09 June 2003 12:57
To:
Andre Kramer
Cc:
'Rich Thompson'; wsrp@lists.oasis-open.org
Subject:
Re: [wsrp] Should URL rewrite expressions be required to be valid for the mime type?

Hi Andre

Andre Kramer wrote:

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)?
Don't know what that last sentence means. Here's my dilemma anyway. If I want to generate XHTML that includes a hyperlink that gets rewritten as a blocking action link I would have to output something like the following:

<a href="wsrp-rewrite?wsrp-urlType=blockingAction&wsrp-interactionState=xxx/wsrp-rewrite"/>

But yet, the above wouldn't parse as XML before it is rewritten (&wsrp-interactionState... isn't a character entity) and if I were to attempt to generate it from a DOM object tree (e.g. using a JAXP document factory, or perhaps after doing some "web-scraping" with JTidy) it simply wouldn't be possible for me to generate this character sequence: I would always end up with:

<a href="wsrp-rewrite?wsrp-urlType=blockingAction&amp;wsrp-interactionState=xxx/wsrp-rewrite"/>

 
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>
I think this is overkill. It wouldn't be possible to perform the rewrites at a character stream level (one would likely have to parse the XML document just to output it) and how would it work for attributes?
 
regards,
Andre
Regards

Dave

-----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


--

David Ward
Principal Software Engineer
Oracle Portal
Oracle European Development Centre
520 Oracle Parkway
Thames Valley Park
Reading
Berkshire RG6 1RA
UK
Email:
david.ward@oracle.com
Tel:
+44 118 924 5079
Fax:
+44 118 924 5005






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