[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