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?
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Mon, 9 Jun 2003 09:32:13 -0400
If you try the provided example in an
XML document type, you will find that the script has to use "&".
I would agree that we don't need to argue about what is legal XML, but
do think that we need to require that the fragment output is valid for
its indicated mime type.
Rich Thompson
| Andre Kramer <andre.kramer@eu.citrix.com>
06/09/2003 09:12 AM
|
To:
wsrp@lists.oasis-open.org
cc:
Subject:
RE: [wsrp] Should URL rewrite expressions
be required to be valid
for the mime type? |
Say a XHTML fragment (an XML MIME
type) contained a script that had a window.open("rewrite-url").
Should the developer have to write "&"s in the rewrite-url?
I think a simple "&" should be allowed (but a "&"
is equally acceptable from the wsrp view point?) and I don't wish to argue
whether or not this is XML or legal script. So both should be allowed always
and we don't need to get into content type details.
regards,
Andre
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 09 June 2003 13:56
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] Should URL rewrite expressions be required to be
valid for the mime 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
"&" 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&wsrp-interactionState=xxx/wsrp-rewrite"/>
Or even use a mix of "&" and "&". I realize
the spec uses only "&" but I thought the proposal was to
use "&" or "&" 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 "&" are allowed in consumer
re-write expression as separators. Content authors are encouraged to use
"&" 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&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
|
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]