OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

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


Subject: RE: [wsrp-wsia] [change request #191] Namespace prefixing


It is just a comment to get implementers to think about the solution they 
choose. The safest thing is to always start the prefix with an alphabetic 
character, but I don't think we should be requiring such things in the 
specification.

Rich Thompson




Andre Kramer <andre.kramer@eu.citrix.com>
02/28/2003 12:59 PM
 
        To:     wsrp-wsia@lists.oasis-open.org
        cc: 
        Subject:        RE: [wsrp-wsia] [change request #191] Namespace 
prefixing


I'm then worried about different scripting languages and markups having
different rules for allowed characters in names.

If Javascript namespacing prefixes only have to be unique, the producer
could add a prefix such as "__jsnsp" if the consumer supplied a numeric
value (or even hex encode weird chars).

That would keep the issue from impacting the protocol? Is this correct, or
can the consumer rely on the producer using the exact value in some way? 

regards,
Andre

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 28 February 2003 17:41
To: wsrp-wsia@lists.oasis-open.org
Subject: [wsrp-wsia] [change request #191] Namespace prefixing


Document: Spec
Section: 10.3
Page/Line: 63/12
Requested by: Chris Braun & Rich Thompson (merged 2)

Old text: Aggregating multiple Portlets from different sources can 
potentially result in naming conflicts for various types of elements: 
named attributes, JavaScript functions and variables, etc. Such tokens 
SHOULD therefore be encoded to a Portlet-instance specific namespace 
[A301]. The Portlet MAY do this by prefixing the name of the resource with 

the namespacePrefix from the RuntimeContext structure.

New text: Aggregating multiple Portlets from different sources can 
potentially result in naming conflicts for various types of elements: 
named attributes, JavaScript functions and variables, etc. Tokens needing 
to avoid naming conflicts when appearing multiple times on a page MUST 
therefore be encoded to a Portlet-instance specific namespace [A301]. The 
Portlet MAY do this by prefixing the name of the resource with the 
namespacePrefix from the RuntimeContext structure. We note that the 
JavaScript examples exclude the possibility of starting such prefixes with 

a numerical character.

Reasoning: 
[CB] There should be some rules regarding what the consumer can produce 
for the resulting token syntax.  The token should be a valid javascript 
identifier for example.  There may be other rules that we need to apply 
here as well. For example, if a consumer uses a numeric namespace this 
would produce invalid javascript in cases where a method or function is 
being namespaced.

[RT] The should relative to how encoding needs to happen isn't strong 
enough. Propose a MUST on what is required with a MAY on a reasonable 
technique.



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


Powered by eList eXpress LLC