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


Title: RE: [wsrp] Namespacing revisited

Rich made two assumptions that I'm not sure about:

- the script needs to be executable as is (so we can't use "-" for Java). We can't guarantee this for all scripting langs.

- we need to be able to find the end of the token being re-written (which we can do using urlType=namespace today)


If we give up on the above requirements (for script writing) then a simple reserved token of "wsrp-rewrite-" would do, and be much simpler for script authors to use.

I would then still keep the current urlType=namespace scheme, as this allows better token handling for cases when we do need to find the end of the token (using a space is going to be to fragile in my opinion and I happen to like the ?&= query string format, even if I have to remember the / at the end :-)

regards,
Andre

PS With this we only need the namespacePrefix field to be required for templates / producer writing which it is already.

-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: 13 June 2003 04:47
To: WSRP OASIS
Subject: Re: [wsrp] Namespacing revisited


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

I second this. The section on URLs would be simpler if the namespacing
issue is dealt with separately.

A reserved token (e.g., wsrp-namespace) for the prefix would be lot
simpler for both portlet developers and consumers.

Subbu



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



You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php



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