XML Binding Language Use Cases and Requirements Version 1.0

Abstract

The charter of the Web Application Formats (WAF) Working Group includes a specification for an XML Binding Language (XBL). This document describes use cases and high-level requirements for this declarative language and thus will be a useful input when creating a specification for an XML Binding Language. Additionally, this document provides some useful information regarding the scope of an XML Binding Language and thus may be useful to others (e.g. other Working Groups, etc.).

The requirements in this document have been derived from several sources including American Online's XBL version 1.0 [XBL1.0], the SVG Working Group's XML Binding Language for SVG [SXBL] and Mozilla Foundation's XBL version 2.0 [XBL2.0].

This document is purely informational and contains no conformance statements or testable assertions.

The WAF Working Group provides these requirements for general information and as of the date of its publication makes no commitment that any of the requirements will be satisfied in a follow-on specification for an XML Binding Language.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the first publication of the XML Binding Language Use Cases and Requirements 1.0 document. It has been produced by the Web Application Formats Working Group, which is part of the Rich Web Clients Activity.

Comments and discussion on this document should be sent to public-appformats@w3.org (public archives).

Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Table of Contents

1 Introduction
    1.1 Terminology
2 Use Cases
    2.1 UC1 - Extension Mechanisms
    2.2 UC2 - Presentation and Behavior Encapsulation
    2.3 UC3 - Presentation and Behavior Inheritance
3 Requirements
    3.1 General
    3.2 Bindings
    3.3 Content
    3.4 Events
    3.5 Error Handling

Appendices

A References
B Acknowledgements

1 Introduction

An XML Binding Language is a declarative language that defines generic mechanisms to bind an arbitrary XML element to a binding element that defines the behavior and/or presentation of the arbitrary element. This mechanism can be used to separate or hide elements of an XML vocabulary from its presentation or behavior. Such mechanisms facilitate re-use of a binding by different applications.

A declarative language is characterized by its focus on describing a problem space via a set of conditions/constraints rather than defining a specific solution to a problem. This abstraction provides several advantages for an XML Binding Language as illustrated by the Use Cases in this document.

1.1 Terminology

A binding is the definition of behavior that can be applied to an arbitrary XML element so as to define its presentation.

An XBL subtree is a subtree in an XBL document fragment, the subtree having as its root node an xbl element in the XBL namespace, that is used to define bindings.

The term binding document is used to mean a document containing an XBL fragment that itself contains XBL subtrees.

A bound element is an element in an arbitrary XML namespace, to which a binding has been applied.

A bound document is a document containing an XBL fragment with one or more bound elements.

The shadow tree for a bound element is the subtree of nodes that are attached to a bound element as a result of XBL processing. The contents of the shadow tree augment the bound element's standard presentation and interactive behavior with alternate behavior. However, the shadow tree is hidden from normal DOM processing (hence the name "shadow"). The shadow tree is attached to the bound element. Once attached, the shadow tree can be accessed only via XBL-specific DOM extensions and therefore is not accessible via Core DOM navigation facilities such as firstChild or nextSibling.

The term shadow content refers to the various nodes in the shadow tree of a bound element. Shadow content is created by cloning a shadow content template during binding attachment.

An XBL application is an application that can interpret XBL i.e. apply the semantics as defined in an XBL specification. In this document, an XBL application is said to interpret an XBL document fragment i.e. process the XBL fragment.

2 Use Cases

This section describes several Use Cases for an XML Binding Language.

2.1 UC1 - Extension Mechanisms

A major use of the XBL declarative language is to extend an XML vocabulary. For example an XBL binding element can define an event handler that will be added to a bound element (when the bound element is interpreted). Additionally, an XBL binding element can be used to change the behavior of an XML element e.g. adding a menu to a button, changing how a scroll bar functions, adding a new menu option to a pulldown menu, etc.

An XBL binding can also specify the arbitrary content i.e. the child elements that is added to a bound element (when the bound element is interpreted).

Additionally, XBL can be used to define a new element i.e. a custom element that can then be used by an XBL application.

Although a declarative language such as XBL should reduce the overall need for scripting, to address applications which require some scripting support an XBL binding may contain embedded code (e.g. JavaScript). This functionality enables language-specific features e.g. providing DOM access to the hosting document when JavaScript is used.

2.2 UC2 - Presentation and Behavior Encapsulation

The XML Binding Language can be used to define an arbitrarily complex binding (e.g. the behavior of an element, the presentation of an element, etc.). That binding can then be used by any XBL user agent either directly (i.e. embedding the binding) or indirectly (i.e. refer to the externally defined binding). This encapsulation functionality facilitates reuse and thus has several positive side-effects such as reduced maintenance, reduced testing, etc.

By re-using existing bindings (particularly external references), a document can be simplified i.e. a complex binding can be attached to the document by a single reference to a binding. This is especially useful when an XBL application needs to make multiple references to a single binding. Additionally, smaller document size may be useful in scenarios where there is low network bandwidth.

2.3 UC3 - Presentation and Behavior Inheritance

The content in a binding can be defined such that it inherits its values from the hosting XBL application or any arbitrary XML vocabulary. This usage facilitates customization of behavior and presentation of the XBL application. As a further convenience for the author of an XBL binding, a binding's definition may include a default value that will be used if no value is inherited.

3 Requirements

This section defines high-level requirements for an XML Binding Language. The requirements are derived from the above Use Cases, [SXBL], [XBL1.0] and [XBL2.0]. The categories are provided for the convenience of the reader. Although some of the requirements could be placed in multiple categories they are only listed in one.

3.1 General

The XML Binding Language's general requirements are:

1. The language must provide a mechanism to define the behavior and presentation of a bound element.

2. It must be possible to assign/associate a binding to an element by using a CSS property.

3. If an XBL application supports DOM, the binding element's DOM tree must be hidden from the bound element when the application interprets the binding.

4. The semantics of a document must not be changed by any binding associated with the document.

5. After a binding is attached, its shadow tree can be accessed only via XBL-specific DOM extensions (and therefore is not accessible via core DOM APIs).

6. A binding definition must be able to state whether or not its content may modify the binding via an XBL-specific DOM method.

7. An XBL document must not contain another XBL document.

8. All of the elements in the XBL namespace must be uniquely identifiable.

9. An XBL specification must specify a security model.

3.2 Bindings

The requirements for a binding are:

1. An XBL document must be able to define multiple bindings.

2. A binding must be able to be directly included (i.e. embedded) in an arbitrary XML application.

3. A binding must be able to reference an external binding (e.g. by using a URI). However, there must only be one level of indirection.

4. A binding must be able to act as an attachment mechanism (to allow a single element reference to be replaced by a bound element when the document is interpreted).

5. A binding must be able to specify additional behavior for the bound element.

6. A binding may contain any element outside of the XBL namespace.

7. A binding should be able to specify that its elements (e.g. content) can be styled by CSS properties defined in the bound document.

3.3 Content

The requirements for a binding's content are:

1. A binding must be able to include any arbitrary XML content (i.e. an element tree from a non-XBL namespace) and such content will be added to the bound element's shadow tree (when the bound element is interpreted).

2. A binding must be able to explicitly define the location of its content in the shadow tree.

3. A binding must be able to specify that only specific elements (and not other elements) can be inserted into the shadow content tree.

4. A binding must be able to specify that specific elements can be inserted into specific places (i.e. insertion points) in the shadow content tree and that other elements can be inserted into other places.

5. A binding's content must be able to include executable code.

3.4 Events

The requirements regarding events are:

1. The language must provide a mechanism to specify a binding's event listeners.

2. When an event is received by a bound element, if a corresponding event listener has been defined, the event must be forwarded to that listener.

3. The processing model for binding attachment and detachment must be defined.

4. The event flow through a binding must be specified.

3.5 Error Handling

The error handling requirements are:

1. When an error conditions occurs, the expected behavior (e.g. stop, continue, report error, etc.) of an XBL application must be documented.

2. When an error condition occurs, a graceful fallback should be defined when appropriate.

3. An XBL specification must identify all error conditions.

A References

[SXBL]

SVG's XML Binding Language (sXBL), Jon Ferraiolo, Ian Hickson and David Hyatt Editors, W3C Working Draft 15 August 2005, http://www.w3.org/TR/2005/WD-sXBL-20050405/. Latest version available at http://www.w3.org/TR/sXBL/.

[XBL1.0]

XBL - XML Binding Language, David Hyatt Editor, W3C Member Submission 23 February 2001, http://www.w3.org/TR/2001/NOTE-xbl-20010223/. Latest version available at http://www.w3.org/TR/xbl/.

[XBL2.0]

XBL 2.0, Work in Progress, last update 06 December 2005, Mozilla Foundation. http://www.mozilla.org/projects/xbl/xbl2.html.

B Acknowledgements

The editors acknowledge the following contributors:

@@@@
...

The WAF Working Group also acknowledges the Editors of the following documents:

XBL version 1.0 - David Hyatt
SVG's XML Binding Language - Jon Ferraiolo, Ian Hickson, David Hyatt
XBL version 2.0 - Mozilla Foundation