Interoperability Use Cases And Requirements

From MemberWiki

Jump to: navigation, search


Interoperability Use Cases and Requirements


This page identifies the use cases and requirements for Ajax toolkit interoperability.

The initial focus of the Interoperability committee is toolkit interoperability. Thus, the focus is to allow Toolkit-A to host components from Toolkit-B and vice versa in an optimal manner such that customer success is optimized. (Note: in the context of this document, the term "toolkit" means client-side JavaScript libraries delivering Ajax functionality.)


  • This document prioritizes items with the words MUST (needs to be addressed immediately), SHOULD (highly desirable to address immediately), and MAY (desirable to have right away but can be addressed later).
  • [?] means that this line item has not yet been discussed yet.

Use Cases

[?] Mixing toolkits within a host HTML page (e.g., integrating Toolkit-A widgets with Toolkit-A widgets)

  1. [?] MUST support runtime integration (need to reword)
  2. [?] SHOULD support IDE integration (need to reword)
  3. [?} (Using JavaScript in this case?)

[?] (For declarative markup interoperability scenarios) Mixing toolkits within a top-level page description markup language (e.g., integrating widgets from Toolkit-A into TIBCO-GI or Backbase) (ACTION: Kevin)

  1. [?] At authortime, a developer MUST be able to describe instances of components from one or more toolkits using an XML syntax. (Does not mean widgets are available only via XML. Still can use without XML. Just means that an XML version alternative must be available to be OpenAjax compatible. Absolutely OK for each toolkit to define its own XML for its components. Needs to be well-formed XML, not constrained to XHTML-Strict.)
  2. [?] For any subsection of a markup, developer MUST be able to choose which toolkit's XML markup format to use so that AJAX componentry innovation is not constrained by a limited set of declarative markup tags, the way HTML had to be iterated upon by a standards body. Open standards are not the same as open systems. AJAX needs to remain an open system, extensible and malleable. That's where the power lies.
  3. [?] Any visual or non visual component from one toolkit must provide a pointer and programmatic access to the data to which it is bound. For example I want to be able to embed a widget from a different toolit, then get access to its data (not just its onscreen view).

Integrating toolkits into AJAX IDEs (ACTION: Phil - 1st pass 6/20 )

  1. Ajax IDEs SHOULD support using multiple toolkits on the same HTML page
  2. Toolkits MAY provide metadata describing thier components to IDEs

[?] Drag and drop use cases (ACTION: Kevin)

  1. [?] End user MUST be able to start a drag event in a visual component from one library and perform the complementary drop event over a visual component in another library.
  2. [?] Runtime components MUST be able to handle drag and drop type matches and mismatches.
  3. [?] Runtime components SHOULD be able to handle intermediary events (such as dragging over a drop type match or mismatch before a drop event) occuring between drag event initiation and drop event conclusion.

[?] Google Finance use case (ACTION: Jeremy to flesh out)

  1. [?] First item
  2. [?] Second item

[?] MeasureMap use case (ACTION: Jeremy to flesh out)

  1. [?] First item
  2. [?] Second item

[?] Brainstorm use cases

  1. [?] Most fundamental is using components from different kits and enabling them to work with each other. Play nice case.
  2. [?] Drag and drop action across kits.


Notes to our brave volunteers who will be fleshing out requirements:

  • Each requirement needs to define the topic in sufficient detail that we can all understand what the requirement is about. Maybe each high level bullet needs a description section.
  • Remember to prioritize requirements via MUST/SHOULD/MAY as they relate to interoperability, where MUST is used for an interoperability requirement that must be addressed right away, SHOULD is used for an interoperability requirement that would be highly desirable to have right away, and MAY is something that is desirable but can be addressed later.

Here is the list of requirements:

[?] General

  1. [?] MUST not paint ourselves into any corners
  2. [?] MUST focus on simple, low-hanging fruit approaches
  3. [?] MUST adopt general principle of doing simultaneous work on implementations and interoperability specifications
  4. [?] MUST have minimum requirement that everything must work in native browser contexts
  5. [?] MUST be able to implement web sites that conform to Open Ajax architecture without Flash, Java or .NET and without server-side preprocessing. (Note: This group's design center is on standard browser technologies. We aren't against these technologies; on the contrary, we SHOULD define integration points where these technologies can be used in conjunction with browser technologies.)
  6. [?] MUST be based on a clearly defined processing model
  7. [?] MUST coordinate with the Declarative Markup committee's work.

[?] Versioning

  1. [?] Any OpenAjax-defined technologies MUST have a robust approach to versioning

[?] Side Effects

  1. [?] All event handlers MUST return DOM to a state that allows modification by foreign script
    1. For discussion: James McParlane has ignited a bit of controversy over his suggestion that toolkit authors "never use Object.prototype to extend the base 'Object'". Prototype.js does this very thing, so some discussion amongst OAA members would be invaluable. (Note: James is not a contributor to the OAA, at the moment; he's simply a Javascript ninja on the public internets.) The issue is not a new one, but it is a high-priority item for Merced Systems to resolve.
  2. [?] Any local persistent storage MUST have no side effects on foreign widgets use of local persistent storage (or instead should there be a way for child widgets to leverage parent storage via APIs?)
  3. [?] [Added 6/9/06 by Jon - this is a controversial issue that we need to discuss] Toolkits SHOULD not be destructive with original widget markup, which SHOULD be preserved to allow people using the toolkits to script against the original widget markup.

[?] Widgets

  1. [?] MUST be derived from a base component or implement a component interface
  2. [?] MAY Support Basic Widget Components (See component below)
    1. Buttons (Radio, Checkbox, Button, Image Button)
    2. Toolbars
    3. Pane/Scrollpane
    4. Trees
    5. Menus
    6. Notebooks
  3. [?] MAY Support Complex Widget Components
    1. Calendar
    2. Discussion Boards/Forums
    3. Maps
    4. Widget Aggregation
  4. [?] MUST support my Fluberator widget (once I get around to actually inventing it sometime in the future)

[?] Load/unload handler coordination (ACTION: Alex)

  1. [?] MUST be non-destructive for previously assigned window event handlers
  2. [?] MUST provide coherent, consistent cross-browser behavior
  3. [?] MUST provide a mechanism for adding multiple, scoped event handlers
  4. [?] MUST squelch exceptions based on an oaa-object flag to not halt execution
  5. [?] MAY attach to "DOMLoad" event instead of default "onload" event

[?] JavaScript namespace coordination (particularly window-object-level)

  1. [?] MUST define a technology solution that is robust and survives scalability when Ajax is used on a broad basis
  2. [?} SHOULD provide a mechanism to coordinate entire industry

[?] Event model (ACTION: Alex)

(Added by JF 20060719) Here are some use cases specific to events that come from Anil Sharma of Vertex Logic, all of which assume a scenario where parent components and child components come from different client-side Ajax libraries:

  • Button sets it state by querying the state of the parent button bar.
  • A field renders itself by querying its value from its container form.
  • JavaScript code finds a component in the hierarchy by its name.

The items above need to be integrated somehow with the following items, which are more focused on raw functionality:

  1. [?] MUST Support Event Listeners
  2. [?] MUST Support Event Triggers
  3. [?] MUST Support Event Delegation
  4. [?] MUST Support Extendable Event Model (Inheritance)
  5. [?] MUST Support Support Component Model (Event Source)
  6. [?] SHOULD Contain Timestamp of Event
  7. [?] SHOULD Contain Event Type
  8. [?] SHOULD Contain Source Object of Event
  9. [?] (Added by JF 20060719) MUST Support Widget-Specific Events (i.e., custom events)

[?] Container widgets (ACTION: ChrisM/ChrisS)

  1. [?] MUST allow container aggregation
  2. [?] MUST support component model
  3. [?] MUST support inclusion of foreign widgets via component model
  4. [?] MUST support container event notification/delegation

[?] Component model (ACTION: ChrisM/ChrisS)

A component is a reusable building block that can be combined with other components in manor to form an hiarchy, framework or an application.

  1. [?] MUST support component id (GUID)
  2. [?] MUST support container model (aggregation of components)
  3. [?] MUST support inheritance of components
  4. [?] MUST support an event delgation model (See event model)
  5. [?] MUST represent visual and non visual components
  6. [?] SHOULD derive from the same top level parent
  7. [?] SHOULD be Model only (MVC2)- View is support through renderers (See RenderKits)
  8. [?] SHOULD support a simple name
  9. [?] SHOULD support visual styles (height, width, size, color)
  10. [?] SHOULD support visual behaviors (visible, dragable, sizeable)
  11. [?] SHOULD support visual definition id or overriding of definition (like CSS id)
  12. [?] MAY support dynamic properties on component

[?] Drag and Drop (ACTION: Kevin)

  1. [?] MUST publish drag and drop related events to the common event system described elsewhere in this document.
  2. [?] Drag event message published to common event system MUST include reference to Drag Source, Drag Type, Drag Controller, Array of references to items being dragged, Toolkit Name
  3. [?] Drop event message published to common event system MUST include message with ??Drag Event ID?? back to Drag Controller
  4. [?] Visual components which are potential drop targets SHOULD implement onBeforeDrop message listeners to handle events and interactons before a final drop event occurs (such as providing a visual indicator of drop type match or mismatch).

[?] Behaviors (e.g., draggable, editable, movable, ***able)

  1. [?] MUST also effect foreign widgets that are included as children/descendants
  2. [?] Second item

[?] Effects (e.g., animation)

  1. [?] MUST also effect foreign widgets that are included as children/descendants

[?] Data binding (ACTION: Jen to flesh out this topic, but TBD who from Adobe would do this work)

  1. [?] Do we need APIs to allow foreign widgets to participate in host environments data binding?

[?] Data Objects (added by Kevin 6/19/06)

  1. [?] Components MUST be able to return their data or a pointer to their data
  2. [?] Such non-visual data objects SHOULD provide a dual XML, JavaScript interface such that data manipulations can occur using either syntax.
  3. [?] Toolkits MAY implement a Common Data Format (or methods that transform to/from such formats) such that data objects from one toolkit can be displayed and/or modified by Widgets from another toolkit in a predictable manner.

[?] Communications (e.g., HTTP)

  1. [?] MUST allow foreign child widgets to establish communications (?? security implications ??)

[?] Introspection

  1. [?] First item
  2. [?] Second item

[?] Back button and bookmarking

  1. [?] First item
  2. [?] Second item

[?] Undo

  1. [?] First item
  2. [?] Second item

[?] Rendering

Rendering is the process of generating a view or output data based on a single component or aggregated set of components to create final code. Render kits are dynamic/plugable code generators to product output like HTML, XUL, XAML or to specific toolkit support using the same component model(data).

  1. [?] MUST take any component conforming to the component model as input
  2. [?] MUST support overriding of renderers
  3. [?] MUST support various render kits

[?] Pluggable looks and feels and styling

  1. [?] MUST be able to dynamically a components theme realtime
  2. [?] MAY use CSS to support theme support plug and play
  3. [?] SHOULD support a standard set of themes

[?] Internationalization

  1. [?] MUST Support message separation
  2. [?] MUST Support dynamic loading of resources (Text, Images, etc)
  3. [?] MUST Support resource bundles for different locales

[?] Accessibility

  1. [?] First item
  2. [?] Second item

[?] Security

  1. [?] MAY Support Authorization of Components (Copyright protection, validation)
  2. [?] MAY Support Encryption/Decryption/Obfuscation of Components (IP Protection)
  3. [?] MAY Support Authorization of Components (Who can use the component)

[?] Diagnostics and logging (ACTION: Adam to flesh out)

  1. [?] MUST be simple to enable/disable
  2. [?] MUST have minimal runtime cost when disabled
  3. [?] MUST be extremely simple and easy to use
  4. [?] SHOULD define a JavaScript mechanism for posting string messages with different levels of severity (e.g. error/warn/info)
  5. [?] MAY carry additional parameters with messages such as exception, source, label, timestamp
  6. [?] SHOULD have a way to intercept and redirect messages within the browser (e.g. to IDE console, server process...) Hint: events
  7. [?] SHOULD be easy to filter messages on individual handlers (may be an implementation detail of handler?)
  8. [?] MAY provide standard API in the oaa namespace
  9. [?] MAY provide default handler implementations to log to client and to server
  10. [?] MAY define a standard serialization or serializations and schema for these messages
  11. [?] MAY define assert APIs
  12. [?] MAY define timing and measurement APIs
  13. [?] MAY provide string substitution mechanism? data types? (probably not... getting away from simple?)

[?] Dynamic addition of widgets

  1. [?] MUST allow for widgets to be added dynamically any time during page life cycle via scripting, including after load event processing has completed.
Personal tools