RE: [wsrp] Namespacing revisited

["Tamari, Yossi" <yossi.tamari@sap.com>]

Hi,

 

I think #2 is important for another reason:

Many development tools parse the scripts internally in order to do things like intelisense, color coding, etc.

In this case preprocessing will not solve the problem.

We don't want to break these tools, so we must keep the script legal even before parsing.

 

    Yossi.   

 

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Friday, June 13, 2003 6:02 PM
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] Namespacing revisited

#2: I have authored enough nontrivial scripts to know that debugging them in both stand alone and integrated modes is important. While we are not likely to be able to ensure requirement #2 for all scripting environments, we should endeavor to support it for both ECMAScript and VBScript.

#3: The last time we visited this area, the number of parsing passes a Consumer is required to make was a significant issue. Why would it have gone away now?

Rich Thompson

Andre Kramer <andre.kramer@eu.citrix.com> 06/13/2003 10:42 AM

To:        Rich Thompson/Watson/IBM@IBMUS, wsrp@lists.oasis-open.org         cc:                 Subject:        RE: [wsrp] Namespacing revisited

For 2, I would favour *not* being able to directly execute so that we ensure that the producer has set the requires re-write flag and that the consumer has found & done the re-write!
 
By the way, I think 3 is not going to be very clean if we use the same token ("wsrp-rewrite") both as a begin / end token pair (url use) and as a stand-alone marker, but could live with such warts.
 
-- Andre
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 13 June 2003 15:18
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] Namespacing revisited


Andre makes a good point ... we should step back and agree on the requirements before we spend more time debating solutions.

My original post looked at the following being the requirements for a constant prefix that indicates a namespacing need:
 1. Clarity of the item after indicating need to be namespaced
 2. Ability to directly debug scripts containing namespaced items (functions and variables)
 3. Consumer only needs to execute a single parse on the markup to do all rewriting (URL and namespacing)
 4. Ability of a Consumer to find the end of the token

We should debate whether all these are required and whether anything important has been missed.

I agree that #4 was inadvertent and likely unnecessary. I think the first three have been stated as needed by various communities and therefore should be accommodated.

Rich Thompson

Andre Kramer <andre.kramer@eu.citrix.com> 06/13/2003 05:02 AM

To:        "'Subbu Allamaraju'" <subbu@bea.com>, WSRP OASIS <wsrp@lists.oasis-open.org>        cc:                Subject:        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