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] Namespacing revisited



I would put the 'wsrp-rewrite?wsrp-urlType=namespace&wsrp-token=.../wsrp-rewrite' next to the 'QXqKYZJVUWj7G' token from the readability perspective. Granted that most of this will be hided by a higher level framework (ie JSR168) but if you need to debug things will be nasty.

IMO, wsrp-rewrite?.../wsrp-rewrite should be restricted for the purposes of constructing URLs.

Using a prefix it's much more readable, #PREFIX#doNothing(). And note that the consumer does not need to generate a unique prefix upfront, it could handle a special token and resolve the prefix at consumer rewriting time.

We could also define a wsrp-namespace$ token to be used as prefix when doing consumer rewriting. I wouldn't use the 'wsrp-rewrite$' (as proposed by Rich) as this is an overload that may create confusion.

But if I'm doing producer rewriting, I need the namespacePrefix. That's way I say it should be a required field.

Alejandro

On Thursday, June 12, 2003, at 10:37 AM, Rich Thompson wrote:

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]