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



CSS would be rewritten in the same manner as any other resource. I think Chris is getting at needing portlet defined classes to not conflict with classes defined by other portlets. I do not think this is a problem as any CSS definitions within the fragment are scoped to the fragment, but it is not unreasonable to consider what happens if a portlet developer decides to namespace their CSS classes. With that consideration, I would agree that the simple change required to make it a legal CSS prefix is an appropriate change.

Chris, have you tested whether or not any current browsers support the "_" character in CSS class names?

Rich Thompson



Andre Kramer <andre.kramer@eu.citrix.com>

06/19/2003 03:19 AM

       
        To:        "'Chris Braun'" <cbraun@novell.com>, wsrp@lists.oasis-open.org, Rich Thompson/Watson/IBM@IBMUS
        cc:        
        Subject:        RE: [wsrp] Namespacing revisited



When/how are CSSs re-written by WSRP consumers?

regards,
Andre

-----Original Message-----
From: Chris Braun [
mailto:cbraun@novell.com]
Sent: 18 June 2003 19:10

To: wsrp@lists.oasis-open.org; richt2@us.ibm.com

Subject: Re: [wsrp] Namespacing revisited

I know we did not include CSS as a requirement, however it would be
useful to have the namespace token be a valid CSS identifier as well.
Consider a portlet using its own dynamically generated styles.  Being

able to namespace these styles is highly desirable.

The following is taken from the CSS2 Spec:

In CSS2, identifiers (including element names, classes, and IDs in
selectors) can contain only the characters [A-Za-z0-9] and ISO 10646

characters 161 and higher, plus the hyphen (-); they cannot start with a

hyphen or a digit. They can also contain escaped characters and any ISO

10646 character as a numeric code (see next item). For instance, the

identifier "B&W?" may be written as "B\&W\?" or "B\26 W\3F".

Neither the "_" or "$" are accepted in the current CSS spec.

Based on the errata at:

http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html

"_" was unintentionally left out and will be fixed in future specs.
That still leaves "$" as being illegal.  

I suggest we use "wsrp_rewrite_".  This is valid for all three: CSS,
ECMA, and VBScript.  

Chris

>>> Rich Thompson <richt2@us.ibm.com> 6/18/2003 1:09:58 PM >>>
My reading of the language specs indicate that wsrp_rewrite$foo is a

valid
variable or function name for both JavaScript and VBScript. Simple test

with JavaScript validated it there. VBScript is much less restrictive
with
its names.

I have been deferring any discussion of making the namespacePrefix
field
required until we determine whether or not we will support the prefix
constant idea as this decision could easily change people's view. As

noted
in other threads, it is already required whenever
doesURLTemplateProcessing="true".

Rich Thompson



Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM>
Sent by: Alejandro.Abdelnur@Sun.COM
06/17/2003 06:45 PM

 
       To:     WSRP OASIS <wsrp@lists.oasis-open.org>

       cc:
       Subject:        Re: [wsrp] Namespacing revisited

Is your proposal to use 'wsrp_rewrite$' as token for namespacing?

Is 'wsrp_rewrite$foo' a valid VS or JS function or variable name?

Not clear why 2 is a requirement, or said in other way, I don't see how

can we put this as a requirement if you are using WSRP URLs in the
JS/VB scripts. They are not well formed URLs if using the wsrp_rewrite

tokens.

This does not address my initial concern of making the namespace field

mandatory. At least when using URL templates. If I'm using URL
templates, most likely I won't use wsrp_rewrite tokens, so the consumer

does not have to do any rewriting. But if I want to namespace I'll have

to use the wsrp_token, thus making the consumer to do rewriting.

Alejandro.

On Tuesday, June 17, 2003, at 11:14  AM, Rich Thompson wrote:

>
> Although there was some disagreement along the way, this thread
> appears to have settled down with at least an acceptance of the first

> three stated requirements; namely:
>

>  1. Clarity of the item after indicating it needs 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)
>

> I think #1 requires that we move to using a replaceable prefix such
> that the original is still readable.

> I think #3 requires that whatever is used for the replaceable prefix

> be a variant on what is used for URL rewriting.
> I think #2 requires that this shared token be legal for function and

> variable names for at least JavaScript and VBScript.
>

> This leads back to a proposal I had put onto the table:

>  1. Change the token the Consumer searches for during rewriting to
> "wsrp_rewrite" (makes it legal in script names)

>  2. Define modifiers to this token for different uses:

>       - "$" suffix = namespace prefix

>       - "?" suffix = start of URL rewriting expression

>       - "/" prefix = end of URL rewriting expression

>

> Rich Thompson

>

>

<image.tiff>

>

>

>

>

> 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

>

<image.tiff>

>

>

>

>

>

> 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

<image.tiff>

>

>

>

>

>

>

> 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

>

>

>

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]