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


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



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