wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [wsrp] Namespacing revisited
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Thu, 12 Jun 2003 13:37:35 -0400
It was brought up on today's call that
the primary target for namespacing is not particularly well served by the
current design. lets consider a simple JavaScript function:
function doNothing() {}
To namespace this today, one has to
rewrite it as:
function wsrp-rewrite?wsrp-urlType=namespace&wsrp-token=doNothing/wrsp-rewrite()
{}
Points made about this rewrite:
1. Rather unwieldy and certainly
not obvious that the function name was originally "doNothing"
2. It is not valid to run as
is and this makes testing much more difficult
The question was raised as to whether
we could easily specify a constant prefix token that this author could
use that would leave the code both readable and testable while not requiring
the Consumer to do two parsing passes. Here is a proposal:
1. Define "wsrp-rewrite$"
as a token indicating that a token requiring namespacing follows
2. Require that a space (%20) follow
the token to cleanly delimit the end of the token needing namespacing.
The author would rewrite our example
function as:
function wsrp-rewrite$doNothing
() {}
This almost works. The problem is that
JavaScript names can not contain a "-" character. It would work
if our delimiting token was changed to wsrp_rewrite so that this example
becomes:
function wsrp_rewrite$doNothing
() {}
and the Consumer URL rewriting expression
changes to:
wsrp_rewrite?wsrp-urlType=value&name1=value1&name2=value2.../wsrp_rewrite
Rich Thompson
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]