Difference between revisions of "ALF/architecture/ALF Schemas 1"

Latest revision as of 19:05, 26 June 2007

ALF Wiki Home

Introduction

ALF Event Manager Schemas and WSDL version 1

WARNING: THIS PAGE IS BEING CONSTRUCTED. THE INFORMATION IT CONTAINS IS PRELIMINARY

The proposed version 1 ALF Event schema is presented below.

Some of the features to note are:

1. The provision for extension and versioning using nested "Extension" elements. The approach pursued is based primarily on the recommendations of this article, "Extensibility, XML Vocabularies, and XML Schema" by David Orchard[1]. This is discussed in more detail below.

2. The refactoring of the BaseEvent to divide it into two parts; the part normally set by the tool raising the event and the part normally set by the alf event manager. The primary motivation for this is to establish a structure of elements that can be passed on to the services of "alf compliant" tools. The needs of this structure correspond to those elements that are normally set by the event manager.

3. There are various name changes and a few additional fields

4. The concept of "User" has been simplified to an extensible "credentials" type. There is now no assumption that a user will be represented by a name, login and password.

5. The need to declare derived types and services to allow tools to decfine their events has been addressed. The declared services, the event manager and the example service flow services, have been changed to use WS-I complient RPC Literal style. Previously, Document Literal style was prefered but that proved problematic for type overloading. The details are discussed under Vocabularies section (Event Declaration Schema).

NOTE: While the schema and WSDL are valsi an WS-I complient we have discovered that curent versions of some web service tools have limitations that mean they cannot consume the WSDL and Schema. These problems are mostly to do with the use of restricting facets (eg: attributes such as minOccurs="0") Given this we may need to make some minor adjustments to the schema before it is final.

Versioning

The approach to versioning in the ALFEvent schema is as follows

1. Namespace The namespace of the ALFEvent schema is "www.eclipse.org\alf\......\1". The trailing 1 designates the schema as major version 1. If it becomes necessary to version the schema, this namespace will be retained so long as the changes are compatible with the existing schema. That is, existing documents created with the exisitng schema will still validate against the new version of the schema. Generally this means that additions are allowed but the removal of elements, changing of structure or changing of types are not allowed. Changes that make the new schema incompatible require that the namespace be changed. Generally we might expect a version 2 to be incompatible and the namespace to become "www.eclipse.org\alf\......\2". This ensures that there is no confusion between what is compatible and what is not. At this time we do not anticipate the need to make incompatible changes.

2. Designated Extension Points Generally it is not possible to change the structure of a data type in a compatible way. To get around this we designate particular extension points where additiona elements may be added in the future should the need arise. Schema provides a way of indicating that "any" element may follow but it presents some challenges as described here (article reference) The general advice is to create a marker element that contains the "any" since this ensure that whatever is substituted into the "any" is disambiguated from the preceeding elements.

3. Separate Extension Points for different purposes The ALF Event Schema is intended to be specialized by tools to allow them to declare their events. While the same principle is used for both extensions due to versioning and extensions due specialization it is important that these do not clash. Special sections are designated as being instended for Vocabulary extensions and for Custom extensions. These are separate from the various various extension points that are included to handle potential additions to the base schema.

4. Provision for dynamic version selection Event though the goal is for new versions in the same namespace to be compatible with the previous version there may be a need to dynamically detect the version in use. To address this, a specific Version attribute is defined the intent of which is to enumerate all the various version numbers that are covered by the specifc schema. The intent is that a tool that raises events would set this attribute to the approriate value fo the version of the schema they are using when the create an event "document". A consumer of the event "document" can then examine this value as a hint to identify which version of the schema is being used. The problem with this mechanism is that it relies on the originating tool to set the attribute correctly and this is not enforcable.

Schema 1

ALFEventBase_1.xsd

Example 1 Event Document

EventBaseExample_1.xml

WSDL 1

ALFEventManager_1.wsdl

Event Declaration

See Section [Event Declaration Schema]