OpenAjax Hub Specification v06 Issues

From MemberWiki

Jump to: navigation, search

(This wiki page holds a portion of the version 0.6 internal editorial draft for the OpenAjax Hub 1.0 Specification. The home wiki page for the version 0.6 (July 8, 2007) draft specification is at http://www.openajax.org/member/wiki/OpenAjax_Hub_Specification_v06. Version 0.6 is preserved for historical reasons and therefore is out of date.)

(The most current version of the OpenAjax Hub Specification is at http://www.openajax.org/member/wiki/OpenAjax_Hub_Specification.


<--previous       contents--^      next-->


Contents

ISSUES

This appendix lists some of the open and closed issues relevant to this specification. This appendix will be removed before the specification is finalized and published.

The write-ups on this wiki page for individual issues should not go beyond executive summaries. Detailed write-ups should be posted elsewhere and referenced from this page.

OPEN ISSUES (most recent issues listed at top)

Issue 16: Remove conformance requirement for xmlns:<prefix>="<uri>"

Original write-up

The OpenAjax Hub Specification now includes a Conformance Requirement on application developers (i.e., the people who are using Ajax toolkits to build their own applications) that says they must include xmlns:<prefix>="<uri>" declarations for each toolkit that they use within their application. This Conformance Requirement only made any sense when the Hub attempted to address markup scanning issues. Since we have streamlined Hub 1.0 to include a reduced feature set which eliminated the markup scanner, we no longer need this requirement. Also, many people in the Ajax community question whether the future of Ajax should embrace XML Namespaces.

Jon's proposed resolution

Remove this conformance requirement. (However, we should retain the requirement on toolkits that they provide a URI for their library. We are asking for something very small, just a string in URI syntax, which at trivial cost provides a future path towards proper XML and XML namespaces for those segments of the industry that have or move such requirements.)

Issue 15: What characters are allowed in event names?

Original write-up

The obvious proposal is that we allow event names to include any characters supported within strings by the JavaScript language. Since JavaScript 1.3 supports Unicode and most browsers support JavaScript at that level, then this gives us at least a fairly recent version of Unicode, which means (for example) Japanese developers can use most of the Kanji alphabet. (We already have a test case for this, thanks to Howard.)

But we certainly want to have an exclude list. We certainly want to disallow the period character (.) because we use that to separate tokens. Here are characters that people have mentioned so far as characters we might consider excluding:

  • Period (.)
  • Slash (/) - Jon mentioned in a teleconference that we should disallow this one so that to promote the ability to marshall event names from the Hub into other topic systems, such as the one in Dojo and the one proposed for Bayeux, both of which use slash. (But since saying this, he has flipflopped.)
  • Quotes (single and double) - Gideon suggested that think about whether quotes should be excluded.

Jon's proposed resolution

Here is my thinking:

  • As always, keep it simple.
  • If possible, choose an approach that requires no additional code within our reference implementation.
  • There are multiple version of JavaScript, multiple releases of implementations of JavaScript, and multiple versions of Unicode. Because of this, we should not attempt to have our specification define what characters are allowed and not allowed. Instead, put the burden on the developer to restrict event names to those that will be supported by the target browsers for his application.

Taking the above into account, my proposal is that:

  • We allow any characters except period (.).
  • We should include a note that suggests that the developer might avoid using punctuation symbols that might be problematic in certain workflows. We can mention that some toolkits use "/" for a separator (whereas we use period) and that there is a chance that characters that are special to JavaScript, such as quotes, might cause problems should they ever be included in JavaScript source files.
  • We should also include a note that suggests that Ajax toolkits warn their users about using periods within their own event systems.

Some of the email discussion

Check the archives to see the full email discussion. Here is an attempt to summarize some points that have been made:

  • Howard: Let's forbid use of quote characters. It's efficient to change the separator character used in a string. Let's please support a worldwide charset.
  • Bertrand: Safari2 has bugs with its Unicode support which are fixed in Safari3
  • Jon: What do we suggest to toolkits that use a different separator char such as Dojo? What about offering an optional form for the event name as an object, such as {name:"aa/bb", separator:"/"}.

Resolution

No decision yet.

Rationale

No decision yet.

CLOSED ISSUES (most recent issues listed at top)

For issues closed previously, see http://www.openajax.org/member/wiki/OpenAjax_Hub_Specification_v05_Issues

Personal tools