Markup Use Cases And Requirements
Declarative Markup Use Cases and Requirements
This page identifies the use cases and requirements for Ajax declarative markup interoperability.
- 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.
Mixing markup from different toolkits within a host HTML page (e.g., integrating Toolkit-A widgets with Toolkit-B widgets via XML markup)
- MUST support runtime integration (need to reword)
Mixing markup from toolkits within a top-level page description markup language (e.g., integrating widgets from Toolkit-A into TIBCO-GI or Backbase) Variation on previous entry
- We SHOULD pursue approaches which allow toolkit integration with top-level markup languages. (Note: There was considerable discussion on various things relating to markup languages that exist at the top level and want to be "on top" and at the root level of the application. Part of the discussion was whether we needed special requirements for this case or whether this was already covered by the general use case for allowing toolkit integration. For now, we are leaving a SHOULD requirement for integration with top-level markup languages, but it isn't clear whether we have a good grasp on whether there are any special issues with top-level markup languages or even how to describe a top-level markup language.)
Integrating markup into AJAX IDEs
- SHOULD support the ability to integrate Ajax toolkit markup into AJAX IDEs
- This committee is not defining a complete language format for user interfaces; thus, this committee will not define an alternate language to what the W3C is defining within its Web Application Formats working group () or an alternate language to existing UI languages such as XUL, WPF, MXML, or LZX.
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:
- MUST not paint ourselves into any corners
- MUST focus on simple, low-hanging fruit approaches
- MUST adopt general principle of doing simultaneous work on implementations and interoperability specifications
- MUST have minimum requirement that everything must work in native browser contexts
- The Open Ajax architecture and requirements MUST be such that it is possible for vendors and users achieve web sites that conform to Open Ajax architecture and deliver rich internet applications without having to use Flash, Java or .NET or server-side preprocessing. Thus, this group's design center is on standard browser technologies. (Note, however, that we aren't against these other technologies; on the contrary, we SHOULD define integration points where these technologies can be used in conjunction with client-side native browser technologies.)
- MUST be based on a clearly defined processing model
- MUST coordinate with the Interoperability committee's work
- Best practices for Ajax content MUST require conformance to XML () and XML Namespaces specifications ()
- Markup approaches MUST conform to W3C's Compound Document Formats (CDF) specifications ()
- Markup approaches MUST be compatible with W3C's Web Application Formats specifications () including XBL (, )
- [?] [This is a potentially controversial issue that we need to discuss] Toolkits SHOULD not be destructive with original widget markup (i.e., the markup that came down the pipe originally), which SHOULD be preserved to allow people using the toolkits to script against the original widget markup.
- (Note: this item might conflict with the degradability requirement)
- [?] MAY use XML Events for declarative markup for event listeners
- [?] MUST support the ability aggregate and nest the component markup from different toolkits
- [?] MAY support a declarative inheritance model for components
- [?] MUST provide accessor to retrieve any component reference for scripting.
- [?] MAY propagate state of components through hierarchy (e.g. disabling a component may disable its children).
Behaviors (e.g., draggable, editable, movable, ***able)
- [?] SHOULD define a declarative approach for behaviors
Effects (e.g., animation)
- [?] SHOULD define a declarative approach to effects that is compatible with similar facilities in SMIL
- [?] MUST use XPath for any addressing mechanisms used in conjunction with data binding
- [?] SHOULD support propagation of data binding through the component hierarchy (e.g. get/set of values tickles through the hierarchy).
Communications (e.g., HTTP)
- [?] SHOULD support XForms submission for client-server communications
Pluggable looks and feels and styling
- [?] MUST support CSS for styling
- [?] SHOULD define a mechanism for skinning widgets that MAY use features beyond CSS
- [?] First item
- [?] Second item
- [?] MUST allow ability to use XForms markup to represent UI controls to allow for media-independent and accessible expression of human-computer interaction
- [?] Maybe don't understand everyone's markup, but allow opaque passthrough. (Came up in coordination discussions between TIBCO and Dojo)