OpenAjax Registry

From MemberWiki

Jump to: navigation, search

Contents

About this document

This is the home wiki page for all OpenAjax Alliance member discussion about and specifications for the OpenAjax Registry. This wiki page provides overview information on the Registry and discusses the process by which the Registry is developed and maintained.

Other pages contain the technical details about the list of registry entries that have been approved, rejected, or are still under discussion:

Open issues concerning the Registry can be found at:

Feedback

Please send public feedback to public@openajax.org. OpenAjax Alliance members are encouraged to send feedback either to interop@openajax.org or other mechanisms that are available to members, such as this member wiki.

About the OpenAjax Registry

The OpenAjax Registry (the "Registry") is a centralized, industry-wide Ajax registration authority managed by the Interoperability Working Group at OpenAjax Alliance. The Registry maintains an industry-wide list of Ajax runtime libraries and various characteristics of each library. For each library, the Registry lists:

  • JavaScript globals
  • runtime extensions (both JavaScript and DOM)
  • markup extensions (e.g., custom elements, attributes or CSS class names)

The Registry helps prevent JavaScript and markup collisions and provides other benefits as follows:

  • Ajax library developers can use the Registry to:
    • make sure that their JavaScript global objects, runtime extensions (JavaScript and DOM), and library-specific markup do not conflict with names used by other Ajax libraries
    • coordinate their efforts to extend the JavaScript environment such that multiple libraries can share the same names and specifications for their extensions
  • Browser vendors can use the Registry to:
    • make sure that new built-in JavaScript features within the browser do not conflict with names already used within the industry
  • Ajax application developers can use the Registry to:
    • help ensure that any JavaScript globals used within their applications do not conflict with globals used by popular Ajax libraries

Although the Registry is expressed in JSON syntax, it is not meant to be used in runtime scenarios. Instead, its main purpose is as an industry-wide knowledge repository for Ajax developers who wish to conform to industry best practices and avoid runtime collisions.

OpenAjax Registry Process

Registry Format

The source file for the Registry (i.e., /Registry/OpenAjax_Registry.js) is a JavaScript source file that creates global object "OpenAjax.Registry", which holds all of the Registry information. For example:

OpenAjax_Registry.js

OpenAjax.Registry.libraries = { 
  OpenAjax: {...see below for contents of this object...},
  abcLibrary: {...ditto...},
  xyzLibrary: {...ditto...}
}

The registration information for each given Ajax library consists of a JavaScript object:

<prefix>: { 
  namespaceURI: <string>, /* required */
  version: <string>,      /* required */
  to_approve: {
    globals:<array-of-strings>,    /* required */
    markups:<array-of-strings>
  },
  to_acknowledge: {
    globals:<array-of-strings>,
    markups:<array-of-strings>
  },
  comments: <string>,
  specificationURI: <string>,
  extraData: <arbitrary JSON>,
  email: <string>
}

Here we illustrate with OpenAjax Alliance's own library, the OpenAjax Hub, which instantiates a single global object "window.OpenAjax":

OpenAjax.Registry.libraries = { 
  OpenAjax: { 
    namespaceURI:"http://openajax.org/hub", 
    version:"1.0",
    to_approve: {
      globals:["OpenAjax"]
    },
    specificationURI:"/member/wiki/OpenAjax_Hub_Specification"
  },
  abcLibrary: {...similar...},
  xyzLibrary: {...similar...}
}

Libraries must register all JavaScript globals, all runtime extensions, and all markup extensions that they might ever instantiate, including extensions to core JavaScript objects such as Object or Array.

The prefix, namespaceURI, version, and extraData properties

The prefix, namespaceURI, version, and extraData properties are the same as for the OpenAjax.hub.registerLibrary() method. (See /member/wiki/OpenAjax_Hub_Specification_Libraries)

The to_approve and to_acknowledge properties

Some Registry entries represent approved best practices and are simply approved. Other Registry entries are ackowledged for their use in industry, but certain aspects prevent the alliance from clean and simple approval. These two properties identify which features should be approved and which ones simply acknowledged. (See Approved vs acknowledged vs rejected)

The to_approve.globals and to_acknowledge.globals properties

The two globals properties (i.e., to_approve.globals and to_acknowledge.globals) are arrays of strings that lists the global objects and extensions to the runtime environment that might be instantiated by this library.

Each global object is expressed in JavaScript dot notation relative to the 'window' object. Thus, the OpenAjax Hub registers the "OpenAjax" object as an approved global.

Extensions to core JavaScript objects are expressed as new properties on the core JavaScript object's prototype. To illustrate, let's suppose the "foo" Ajax library uses global object foo, and adds grow() and shrink() methods to the Object prototype. It would therefore register the following globals: (Note: these kinds of extensions to core JavaScript objects are usually acknowledged, not approved.)

  foo: { 
    namespaceURI:"http://foo.com", 
    version:"1.0",
    to_approve: {
      globals:["foo"]
    },
    to_acknowledge: {
      globals:["Object.prototype.grow", "Object.prototype.shrink"]
    }
  }

Any name in the list of globals that has an asterisk (*) as its final character indicates a wildcard entry where a given library is registering any possible name that begins with the characters before the trailing asterisk. (See section "Wildcards in globals" below.)

The to_approve.markups and to_acknowledge.markups properties

The two markups properties (i.e., to_approve.markups and to_acknowledge.markups) indicate the list of custom HTML elements, custom attributes, and CSS classnames that are used by the library. The markups property must contain an array of strings, where each element in the array identifies the custom HTML element, custom attribute or CSS classname using the following subset of CSS selector syntax:

  • Simple element type selector, such as mycustomtagname
  • Class selector, such as .mycustomclassname
  • Attribute selector. For custom attributes that can be used on any element, the entry should appear as follows: [mycustomattribute]. For custom attributes that can be used only with specific element, the entry should be expressed as (assuming the attribute appears on DIV elements) div[mycustomattribute].
  • Attribute value selector. For cases where an Ajax toolkit adds a custom value to an existing attribute, the attribute selector should be extended to reflect the custom value: [mycustomattribute="mycustomvalue"] or div[mycustomattribute="mycustomvalue"].
  • Attribute pattern match selector. An Ajax library might use a set of attribute values that all begin with a particular string prefix. For this scenario, the prefix should be specified using substring matching selectors, as in [mycustomattribute^=myprefixstring].

For example, if the "foo" Ajax library uses custom element <foo>, custom attribute bar, and CSS classname foobar, then its entry might look as follows:

markups:["foo","[bar]",".foobar"]

Developers who are authoring the Registry Entry for their Ajax library should be careful about the syntax. Note that it is possible to have two levels of nested brackets and quotes, as in markups:["div[mycustomattribute='mycustomvalue']"].

The asterisk character (*) can be used as the last character for an element selector, class selector, attribute selector, attribute value selector, or attribute pattern match selector to indicate a wildcard specification. For example, suppose the "foo" Ajax library uses a large number of different elements whose tagnames begin with "fooElem", a large number of attributes that being with "fooAttr", and a large number of CSS classnames that being with "fooClass", then its entry might look as follows:

markups:["fooElem*","[fooAttr*]",".fooClass*"]

If the above options are insufficiently expressive to reflect the complexities of the custom elements, custom attributes, classnames or other markup extensions, then describe the additional subtleties within the comments property.

Unless explicitly stated otherwise within the comments property, the community should assume that the given library requires sole control over (i.e., "owns") any element nodes that match against the markups property. For example, suppose the "foobar" library applies major transformations to any elements that contains the 'foobarType' attribute such that other Ajax toolkits are excluded from attaching their own behaviors to the same elements. By listing 'foobarType' within the markups property and not mentioning anything further in the comments property, the community should assume that the "foobar" library "owns" all elements that have a 'foobarType' attribute. For a second example, suppose the "foobar" library uses custom attribute 'foobarRef', but performs no transformations on elements with this attribute, and therefore does not requirement exclusive control over that element. In this case, the Registry Entry should include a note in the comments property to indicate that the "foobar" library does not require exclusive control over elements with the 'foobarRef' attribute.

If your custom element names or attribute names require namespace prefixing, then the entry should conform to the namespace syntax from W3C Selectors. For example, for the <myNS:foo> custom element, the entry would be myNS|foo. There is no formal syntax for associating namespace URIs with namespace prefixes; instead, the comments property should identify the describe the namespace prefixes and namespace URIs used by the library.

The specificationURI and email properties

The specificationURI property provides a URI reference to the specification that documents the Ajax library corresponding to this Registry entry. The specificationURI is optional if the Registry entry only lists JavaScript globals but is required if the Registry entry lists extensions to the JavaScript runtime environment or extensions to the DOM.

The email property provides an email address for questions and/or discussion about the given Ajax library.

The comments property

The comments property is available for free-form, supplemental text for important information that is not expressed in the other properties.

Other sections of this document highlight some of the specific information that is expected in the comments property.

Required and missing properties

The only required properties are namespaceURI, version, and to_approve.globals.

Any unspecified properties are equivalent to an empty entry. For example, if property to_acknowledge.globals is not specified, then the meaning is the same as if the registry entry included the value to_acknowledge.globals=[]. Similarly if property comments is not specified, the meaning is the same as if the registry entry included the value comments="".

Wildcards in globals

The globals that are listed in a registry candidate can use wildcard notation, where a common prefix followed by a terminating "*" character matches any globals that begin with the given prefix and have at least one more character after the prefix. For example, if there is a registry candidate global with the name "Foo*", then this candidate global will match "FooA" and "FooABC", but doesn't match "Foo".

In most cases, OpenAjax Alliance will not condone wildcard entries (e.g., Foo*) and in general will not include any wildcard entries within the "approved" section of the OpenAjax Registry. Instead, we feel that the best practice is to have a single global object as the root for a particular toolkit (e.g., Foo.*), in which case only the given global object needs to be registered (i.e., "Foo").

However, some Ajax toolkits leverage this wildcarding approach in debug mode to facilitate debugging within an IDE, and the members of OpenAjax Alliance believe that this is a reasonable technique for improving developer productivity. In any case, we want the Registry to be a good source of information for developers so that they can code their JavaScript in order to avoid name collisions. Therefore, we ask toolkit developers to include their use of prefixing techniques, even if the wildcarding technique is used in a manner that is inconsistent with OpenAjax Alliance's recommended best practices, and even if the Ajax toolkit has deprecated such techniques or intends to deprecate those techniques in the future.

In nearly all cases, because OpenAjax Alliance prefers a single global object over wildcarding, wildcard entries should be listed in the to_acknowledge.globals section of the registry candidate instead of the to_approve.globals section.

Note that in many cases, it is better to explicitly list each global separately (e.g., FooApple, FooOrange, FooBanana) in the registry candidate versus using wildcards (e.g., Foo*) because that provides more detailed and explicit information about what developers should expect. However, when there are large numbers of such globals with a common prefix or if there is uncertainty about which distinct globals were used, then wildcards can be justified.

Process for proposing new Registry entries, review and approval

Registry Candidates

A Registry Candidate is a formal proposal to register a toolkit and its globals, runtime extensions and markup extensions with the OpenAjax Registry. A Registry Candidate ultimately is posted on its own wiki page within the OpenAjax Alliance member wiki.

Who can submit Registry Candidates?

Only members of the alliance can submit a Registry Candidate. The primary reason why only members can submit proposals is that proposals will happen on our wiki and only members have write-access to the wiki.

Non-members can participate indirectly either by contacting someone who is a member of the alliance to submit a Registry Candidate on their behalf or by sending an email which contains the information for their Registry Candidate to public@openajax.org.

We will strongly encourage the practice of having acknowledged leaders for a given Ajax library to create and manage the Registry Candidate submission process. However, if we cannot get the leaders of a particular library to participate in a timely manner and the alliance feels that it is necessary to create a Registry entry for that particular library, then others can create and manage the Registry Candidate.

Location of Registry Candidates

There is a single wiki page that serves as the central listing location (i.e., the index) for the various Ajax toolkits for whom Registry Candidates have been submitted. This wiki page has a single bullet for each toolkit for which registry entries have been proposed:

The above wiki page contains a list of hyperlinks to other wiki pages, one for each separate Ajax library. The wiki pages for each distinct library are named "Registry Candidates for Foo", where "Foo" is the name of the Ajax library. (For example, "Registry Candidates for Dojo")

The wiki page should have a section near the top that holds the suggested JavaScript snippet for the proposed registry entry, such as:

  ACMELibrary: { 
    namespaceURI:"http://example.com/ACME", 
    version:"1.0",
    to_approve: {
      globals:["ACME", "_ACME"]
    }
  }

Other parts of the toolkit-specific wiki page are free format and should contain any supplemental information that is appropriate for the members of the Interoperability Working Group to evaluate and cast judgment on the proposal.

Discussion about Registry Candidates

People's opinions about the Registry Candidate, and other people's responses to those opinions, should be entered directly on this wiki page. It is OK to fork off other wiki pages as appropriate so long as links to the forked discussion are included on the candidate registry wiki page. If some discussion happens on email lists, the participants in the discussion should attempt to migrate the discussion onto the wiki page, or at least include a pointer to the email archives.

Announcement

Once a Registry Candidate wiki page has been created, the author of that page should send email to interop@openajax.org announcing the availability of that page. The chair of the Interoperability Working Group will then schedule discussion at upcoming meetings (usually, phone calls).

Meeting discussion, public feedback, voting and approval

Each Registry Candidate must have been "discussed" during at least one Interoperability Working Group meeting before voting can begin. The chair is responsible for ensuring sufficient advanced notice of registry discussions. "Discussion" consists of including the given Registry Candidate on the agenda of an Interoperability Working Group meeting and allowing attendees of that meeting an opportunity to voice comments that are then included in the minutes. It is OK if the "discussion" is null (i.e., no one has anything to say during the meeting).

After meeting discussion, if the chair determines that the committee members appears to have a preliminary consensus in favor of the Registry Candidate, the chair will then send email to interop@openajax.org notifying the members of that group that discussion has occurred and the dates when approval voting will occur. There must be at least two weeks between the notification email and when voting occurs.

The two week period should solicit public feedback by including a blog posting at the OpenAjax Alliance blog about the upcoming vote on the Registry Candidate(ies) which instructs the public to send feedback to public@openajax.org.

Voting is done electronically on the interop@openajax.org mailing list. Each voting period will last one week.

Any negative vote must be accompanied by an explanation of the Members’ concerns. A negative vote with no explanation is spurious and will not be counted. To resolve any negative vote the members of the Working Group and its chair are expected to reply via interop@openajax.org. The goal is to achieve rough consensus through dialogue.

If all registered votes are in favor of the Registry Candidate, then the chair will ensure that the registry entry will be added to the official OpenAjax Registry (i.e., /Registry/OpenAjax_Registry.js) and the wiki page for the Registry Candidate will be updated to indicate that the registry entry has been approved.

If the chair determines that there is a consensus but there are outstanding unfavorable (and not spurious) votes, then the chair will escalate the decision to the Steering Committee, whose vote will be final and binding.

Criteria for judging Registry Candidates

Overall criteria

The Interoperability WG will judge Registry Candidates based on the following criteria:

  • The Greater Good - The InteropWG will judge the Registry Candidates based on whether the given registry entries makes sense on an industry-wide basis. For example, it makes sense to assign the "gwt" global object to the GWT toolkit because "gwt" is an appropriately named global object for the GWT toolkit.
  • Simplicity - Although this might not yet be represented in any of the OpenAjax Best Practices documents, it is generally considered an OpenAjax Best Practice that Ajax toolkits define as few global objects as possible, preferably at most one.
  • Conflict avoidance - The InteropWG is more likely to approve global variables that have little likelihood of conflict with other JavaScript object names and less likely to approve global variables with high likelihood of conflict. For example, let's assume that an Ajax toolkit uses three global variables, "q", "name" and "w$6thuiQQv". The first one ("q") has high likelihood for conflict because it is short and some developers use short variable names on a global basis. The second one ("name") has high likelihood for conflict with other JavaScript because many applications involve the name of something, so it is less likely that the InteropWG would assign this global variable as reserved to a particular Ajax toolkit. The third one ("w$6thuiQQv") however, has low likelihood for conflict and therefore has a greater chance for approval. In general, the longer the name of a global and less it represents a common term, the better.
  • Reasonableness - Many Registry Candidate are expected to be straightforward (e.g., an Ajax toolkit requesting to be granted a single global object), but the world is complicated, so some Registry Candidates are likely to have unique issues. All other things being equal, the InteropWG should be flexible in addressing reasonable requests that address unique requirements.
  • Existing industry usage - All other things being equal, the InteropWG should avoid going against existing industry practice. For example, if large numbers of users are deploying Ajax toolkits that use global object ZZ$$ for a particular set of useful APIs, then the InteropWG would need a very good reason to allocate ZZ$$ to another toolkit for a different purpose.
  • Alignment with OpenAjax Conformance and industry best practices - For more on OpenAjax Conformance, see /OpenAjax%20Conformance.html.

Each item reviewed individually

A Registry Candidate will contain multiple data items. The InteropWG should evaluate each separable aspect of a Registry Candidate individually. If some of the aspects warrant approval but others do not, then the InteropWG should communicate this information to the group that submitted the given Registry Candidate and determine if a revised Registry Candidate might be possible.

If at the end of such communications there are still some aspects that the InteropWG does not feel it should approve, sometimes the InteropWG will choose to approve parts of the Registry Candidate, acknowledge others, and reject others.

Approved vs acknowledged vs rejected

Any particular data item within a Registry Candidate might be approved, accepted or rejected:

  • Approved: The InteropWG will approve a data item within a Registry Candidate if it clear matches the general criteria listed above.
  • Acknowledged: In some cases, the InteropWG will feel that it cannot approve/condone a particular aspect of how a toolkit deals with global objects, but because of widespread industry adoption of the given toolkit or unique technical requirements, it is not feasible or advisable to reject the given approach. The compromise middle ground is for the InteropWG to "acknowledge" this particular behavior. (Note: Often it is advisable to include a textual note within the OpenAjax Registry that provides a summary description of the behavior, reason why it was not approved, and whatever information the community needs to know about this behavior so that the community will know how to avoid collisions.)
  • Rejected: It is expected that occasionally there will be aspects of particular toolkits that the Interoperability WG feels are not in the interests of the Ajax community and should be explicitly rejected. In these cases, the InteropWG should work with the relevant organization to attempt to persuade them to change their toolkit.

Version management

The philosophy behind the Registry is that all library prefixes and all globals listed in the OpenAjax Registry have a lifetime of forever. Once a prefix or a particular global is allocated to a particular toolkit, that allocation will never be relinquished.

As a result, the Registry entry for a particular Ajax library can only grow over time. If a newer release of a particular Ajax library comes out with a revised set of globals:

  • Any new globals should be submitted via a new/revised Registry Candidate for discussion within OpenAjax Alliance and possible inclusion within the official registry.
  • Any deleted globals that are already in the OpenAjax Registry remain and are not removed, but it is OK to include comments about deprecation of particular features.

Best practices regarding globals, extensions to core JavaScript and extensions to DOM objects

OpenAjax Alliance promotes interoperability across browsers and Ajax runtime libraries. Because of this, we strongly promote a policy in which Ajax runtime libraries do the following:

  • Register all global objects, runtime extensions, and markup extensions with the OpenAjax Registry
  • Create as few global objects, runtime extensions, and markup extensions as possible
  • Provide relocation mechanisms for all features that are not "approved" entries within the OpenAjax Registry. The relocation mechanism provides developers with the option to relocate features that might conflict with other JavaScript logic and markup on the same Web page (e.g., due to inclusion of other Ajax libraries).
  • Avoid extensions or modifications to core JavaScript objects (see discussion below)
  • Avoid extensions or modifications to core DOM objects (see discussion below)

That said, some Ajax libaries (which sometimes call themselves "JavaScript libraries" or "JavaScript frameworks") derive much of their value due to their enhancements to the JavaScript and DOM runtime environments, which is often the result of purposeful extension and/or modification of core JavaScript objects. These extensions can help raise the productivity of Ajax developers by providing "an improved JavaScript".

These extensions to the JavaScript runtime environment, however, represent interoperability challenges to the industry because:

  • Conflicts can arise when two or more Ajax libraries attempt to add the same extension because it is likely that different libraries expect different behavior from the same extension.
  • Even if two Ajax libraries agree today on the same specification for a particular extension, in the future one of the Ajax libraries might decide to modify their implementation of the extension, which might result in future interoperability problems.
  • The standards world and/or browser vendors might decide to enhance browsers with new built-in features that conflict with extensions found in existing Ajax libraries.
  • Bugs can be introduced into Web applications if an Ajax library that extends the JavaScript runtime environments alters the behavior of a particular extension in a manner that breaks backwards-compatibility. Even if the Web application developers read the update notices for a given library, they might not recognize the impact that the new behavior might have on his application and thus allow bugs to be introduced into his application.

In order to strike an appropriate balance which promotes interoperability without losing the productivity benefits from JavaScript language extensions, OpenAjax Alliance defines the following policy:

  • JavaScript language and DOM extensions will be considered for inclusion in the OpenAjax Registry
  • For a particular JavaScript language or DOM extension to be approved:
    • There must be an established and reputable organization or project that will be identified as the owner of the given extension
    • There must be a URL to an immutable document (e.g., URL to a dated version of a specification) that contains a complete definition for the extension, including full definition of its APIs and full description of its behavior
    • There must be a covenant from the owner organization about future versions of the given extension
      • Future versions of the extension will be backwards compatible with the version of the extension that is referenced in the OpenAjax Registry
      • Future versions of the extension will be submitted to the OpenAjax Registry so that the revised extension can be reviewed and (if approved) the Registry can be updated
  • In the case of conflicts between different Ajax libraries (e.g., two libraries each decide to add a "foo" method to the Array object), the Interoperability WG will take into account several factors in deciding whether to accept one extension versus another (or rejecting both). Among the factor are: (a) positive aspects of each proposed extension in terms of value to developers, suitability to purpose, quality of implementation(s), and quality of documentation, (b) negative aspects such as potential conflicts that compromise interoperability (today or in the future) or side effects, (c) usage levels within the industry.

An extension to a core JavaScript object should be listed in the "to_approve.globals" or "to_acknowledge.globals" properties of the Registry entry as an entry of the form (note: extentions usually belong under "to_acknowledge.globals"):

to_acknowledge:{
  globals:[...,"<coreJSObjectname>.prototype.<extension-name>",...]
}

such as:

to_acknowledge:{
  globals:[...,"Array.prototype.foo",...]
}

An extension to a DOM interface should be listed in the "to_approve.globals" or "to_acknowledge.globals" properties of the Registry entry as an entry of the form:

to_acknowledge:{
  globals:[...,"!DOM.<DOM-interface>.prototype.<extension-name>",...]
}

where the 5 letters "!DOM." identifies this as a DOM extension and <DOM-interface> is the name of the DOM interface that is being extended. For example,

to_acknowledge:{
  globals:[...,"!DOM.HTMLElement.prototype.foo",...]
}
.

Conformance requirements to avoid collisions with other toolkits

In some cases, multiple Ajax libraries will attempt to extend the JavaScript environment by adding the same global object, the same JavaScript or DOM extension, or the same markup extension.

A classic case in point is the "$" global object, where two popular Ajax libraries (Prototype.js and jQuery) both recognized the convenience and productivity advantage from offering a single-character entry point to the library's most useful features. One significant problem with the use of the "$" global object is that developers sometimes need to include both libraries within the same HTML page. To address potential conflicts between jQuery and Prototype.js (and potentially other libraries), jQuery offers configuration options that allow developers to control the global variables that jQuery uses (see http://docs.jquery.com/Using_jQuery_with_Other_Libraries). jQuery's techniques represent a good approach for addressing potential name collisions while still providing developers with a high-level of convenience.

Similar conflicts might arise if an Ajax library extends the core objects within the JavaScript language, extends DOM objects or extends the HTML language. An example of extending a core JavaScript object would be adding a String.prototype.contains() method, which very well might conflict with another toolkit that might want to define the same extension, but with a different set of parameters and/or different behavior (e.g., case-sensitive vs case-insensitive comparisons).

Here are conformance requirements to avoid collisions over commonly used global objects, runtime extensions, or markup extensions:

OpenAjax Conformance Requirement: The library MUST have an approved entry within the OpenAjax Registry

(Applies to Libraries. Required for Limited, Configurable and Full Conformance)

To claim Limited, Configurable or Full Conformance, the library MUST have submitted a candidate entry to the OpenAjax Registry that provides the information required by this specification (e.g., global objects, custom markup, etc.) and that entry MUST have been approved using the process defined within this specification.

OpenAjax Conformance Requirement: All non-approved globals and extensions MUST be documented and registered

(Applies to Libraries. Required for Limited, Configurable and Full Conformance)

To claim Limited, Configurable or Full Conformance, the library MUST identify the globals and extensions that might conflict with similar features from other Ajax toolkits within the OpenAjax Registry and provide developer documentation that identifies those globals and extensions. Additional, the library MUST document the mechanisms that are available for addressing the previous two conformance requirements described just above.

OpenAjax Conformance Requirement: All "non-approved" globals and extensions either MUST be relocatable or MUST offer a mechanism to disable

(Applies to Libraries. Required for Configurable and Full Conformance)

To claim Configurable or Full Conformance, the library MUST offer a mechanism to developers such that a developer can either disable any global or extension that is not listed as “approved” in the OpenAjax Registry or control the location of where that global or runtime extension is installed into the runtime environment, and/or the ability to use alternate markup syntax. For example, jQuery provides a configuration option that allows developers to either disable the use of the "$" object as an alias for the "jQuery" object or to explicitly specify an alternate location for that alias (e.g., "$j").

OpenAjax Conformance Requirement: All features MUST be available via "approved" Registry entries

(Applies to Libraries. Required for Configurable and Full Conformance)

To claim Configurable or Full Conformance, the library MUST offer a mechanism to developers such that it is possible to use the library via features that are listed in the OpenAjax Registry as "approved" entries. For example, jQuery makes all of its features available via the jQuery global object. This conformance requirement also applies to JavaScript language extensions, DOM extensions and markup extensions. For example, let’s assume that the fooLib library extends JavaScript by adding String.contains(substring). Perhaps fooLib could offer fooLib.String.contains(string, substring) as an alternative to its String.contains() extension to the JavaScript language.

OpenAjax Conformance Requirement: In its default configuration, all globals and extensions are "approved"

(Applies to Libraries. Required for Full Conformance)

To claim Full Conformance, in its default configuration, a library MUST only use globals and extensions that are listed in the OpenAjax Registry as "approved" entries.

Tools

OpenAjax Alliance has developed some JavaScript tools to help Ajax toolkit developers (and us) to see the changes to the JavaScript environment that result from the use of a particular toolkit. The tools are posted at:

The above files contain JavaScript logic that:

  1. recursively traverse the "window" object to build a list of all descendant objects and properties
  2. compares the results of two traversals and returns a list of differences

A developer can customize the template to load and initialize his favorite Ajax toolkit after the first traversal and before the second traversal. The HTML page then shows the new global objects and properties that have been added due to the toolkit.

An assessment of the OpenAjax Hub can be found at:

Futures

Here is a list of some of the features that have been discussed for possible inclusion in a future version of the Registry. The features listed below may or may not be addressed in a future version of the Registry, and the Registry might be enhanced in the future in entirely different ways than the list below. Nevertheless, here are some features that have been mentioned as possibilities for the future:

  • Topic names - A future version of the Registry might provide an industry-wide registration authority for topic names and payloads for messages, particularly when using the publish/subscribe features in the OpenAjax Hub.
  • Cookie names - A future version of the Registry might provide an industry-wide registration authority for cookie names for situations where Ajax libraries use cookies for library-specific persistent state storage.
  • Element ownership - Right now, we encourage Registry Entry authors to describe within the comments property any situations where an Ajax library does not require sole control over element nodes that match against the selectors listed in the markup properties. In the future, we might change the Registry to add a separate field to declare (probably via CSS selectors) over which elements a library requires sole control/ownership.

Personal tools