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


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.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


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


Powered by eList eXpress LLC