[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Namespacing revisited
Rich Could you clarify why (4) is a requirement? Subbu Rich Thompson wrote: > > 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]