MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [wsia] [wsrp][markup] URL rewriting for proposals 2 & 4
I think there has been enough use cases on the email lists & conference
calls for both options 2 & 4 that I would propose we work on how the
underlying semantics of having both options works. My current thoughts:
- Well defined property names for the templates of option #4
- Decide whether the prefix of option #2 is static to the spec or dynamic
via a property (this choice essentially includes whether or not there is a
recommended a parse algorithm)
- Producer property set includes predefined names if it is willing to use
option #4.
- Consumer metadata indicates whether it is prepared to do URL rewriting
(option #2)
- Compliant Consumers MUST either set template properties OR indicate a
willingness to rewrite URLs.
- Producer options when defining the template properties then become:
- If Consumer set template properties AND indicated it is willing to
rewrite URLS, Producer may choose either option.
- If Consumer set template properties AND indicated it will not
rewrite URLs, Producer must use option #4
- If Consumer did not set template properties AND indicated it is
will to rewrite URLs, Producer must use option #2
- If Consumer did not set template properties AND indicated it wil
not rewrite URLs => non-compliant Consumer.
- Producers not defining the template properties require that their
Consumers support URL rewriting & use option #2
Net effect:
- Producers are not required to support option #4, but those desiring
broadest use by Consumers will.
- Consumers are not required to support option #2, but those desiring to
use the broadest set of Producers will.
- If both options are available, the Producer gets to choose which to use.
I see the email servers messed up the original table ... I have appended a
Word version of it to this email.
(See attached file: WSIA-WSRP URL rewriting.doc)
Gil Tayar
<Gil.Tayar@webcol To: Carsten Leue/Germany/IBM@IBMDE
lage.com> cc: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org
Subject: RE: [wsia] [wsrp][markup] URL rewriting for proposals 2 &
06/18/2002 12:07 4
AM
Carsten,
I understand why option #2 may put less burden on the producer, but in
contrast it may make it more difficult to _debug_ the producer. Option #2
means that the markup produced by the producer is not "valid", e.g. the
links cannot be "followed" by a browser. This means that if behind the
producer is a real HTTP application, it cannot be debugged "offline", or
even checked with HTML validators that check links.
Option #4, on the other hand, always creates valid HTML and links, which
means that the "underlying application" can be tested by sending a "dummy"
Proxy URL.
In any case, the difference in the difficulty for the producer between #2
and #4 are minor. In both cases, URL-s in the underlying applications will
need to be changed by the producer - it's just a question of the change
algorithm (although in the case of "static" HTML pages I do agree that
option #2 is easier).
What I would propose is to enable both. Option #4 is enabled by one simple
argument in the getFragments/performAction - the "Proxy URL" below (which
in
the original draft was named "controllerUrl" and which Thomas and Rich
omitted when moving from the original draft specification to the new draft
specification). The producer metadata (or return value from those
operations) will specify whether URL rewriting was done or not.
Gil