IMS Application Profile Guidelines Technical Manual Part 2 - Technical Manual Version 1.0

Copyright © 2005 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a registered trademark of IMS/GLC
Document Name: IMS Application Profile Guidelines Technical Manual
Revision: 10 October 2005

IPR and Distribution Notices

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright © IMS Global Learning Consortium 2006. All Rights Reserved.

If you wish to distribute this document or use this document to implement a product or service, you must complete a valid license registration with IMS and receive an email from IMS granting the license. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm.

This document may be copied and furnished to others by Licensee organizations registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS work group.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/ap/apv1p0/apv1p0speclicense.html.

The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Executive Summary

This document is the second of two parts which together constitute the IMS Application Profile Guidelines:

• Part 1 - Management Overview;
• Part 2 - Technical Manual.

This Technical Manual describes, from a technical point of view, the profiling of specifications, primarily those developed by the IMS Global Learning Consortium. However, the approach defined in this manual could also be applied to specifications developed by other organizations. In addition to evaluating the methods for defining an application profile, this document provides a means to represent changes to a specification in an XML form. This document also describes a way in which profiles could be tested for conformance purposes, but this is only provided as a suggestion rather than as a normative specification for conformance testing.

The document describes in detail the operations that are available to adapt a specification given by a data model and an XML schema. All these operations may affect interoperability. It is acknowledged that there are situations where nevertheless, the need to deliver community-specific data and services in conjunction with data and services of general relevance requires profiling of a specification. In these situations, the current paper will provide information about the consequences of particular profiling decisions with respect to interoperability and it may contain alternative solutions.

The development of an application profile begins with the establishment of a community of shared interests that can identify the need for an application profile and support its development and maintenance. This community, once established, looks at the requirements of its members, both in terms of existing systems and processes and its future needs. It also needs to take account of the specifications (and existing application profiles) available to it. Once requirements have been gathered, there needs to be a process of analysis and synthesis, where the community produces models of its domain, and identifies gaps in available specifications. It may also develop a reference architecture model to place the specifications within a system design context. At this point, the community has the information with which to make the decision whether or not it is appropriate to create a profile. If the community decides it is appropriate to create a profile, it can then make a choice of specifications and/or existing profiles, and begin development of the application profile. Finally, an initial application profile is created. Profiles need to be published, ideally in a registry of application profiles, so that other organizations wishing to create profiles can locate and reuse existing work. Where this is not applicable or practical, then the profile should at least be published formally with an official identifier.

For each specification utilized that involves a data model of some description, you need to define precisely how that model needs to be adapted to meet your requirements. There are a number of operations that can be used for adapting an information model, each with implications for interoperability within your community or application, and for retaining compatibility with the wider world.

For each operation mentioned below, guidelines are given on how to perform the operation, what the benefits and implications are for your profile and how the intent of the operation can be expressed. The modifications identified below are split into the following categories:

• Restrictive Modifications - instances of the profile can be used by tools and products that correctly implement the base schema in their read profile. The base schema can further be used to export data outside the immediate target community. It is recommended to use only these modifications in write profiles of applications;
• Extensive Modifications - instances of the profile schema may well no longer validate against the base schema and hence tools and products may require some customization to use instances to the resulting profile. Data will also need additional handling to achieve exchange with external communities. These operations are strongly discouraged for use by write profiles and should be adopted only if the communities' needs cannot be addressed by any other means. They are, however, of no harm in read profiles of applications. Applications using extensive modifications in their read profile may well use all instances of the base schema;
• Incompatible Modifications - these operations break interoperability with the base specification completely and should not be undertaken in any circumstances. Note that also the simultaneous usage of restrictive and extensive modifications will result in an incompatible profile.

Table of Contents

1. Introduction

1.1 Scope and Context

This document is the second of two parts which together constitute the IMS Application Profile Guidelines:

• Part 1 - Management Overview;
• Part 2 - Technical Manual.

This Technical Manual describes, from a technical point of view, the profiling of specifications, primarily those developed by the IMS Global Learning Consortium. However, the approach defined in this manual could also be applied to specifications developed by other organizations. In addition to evaluating the methods for defining an application profile, this document provides a means to represent changes to a specification in an XML form. This document also describes a way in which profiles could be tested for conformance purposes, but this is only provided as a suggestion rather than as a normative specification for conformance testing.

The accompanying Management Overview describes what an application profile is in the context of the IMS specifications and the benefits to be gained from undertaking such an exercise - namely more closely meeting the needs of the target user community whilst harnessing the specifications to aid integration and enhance interoperability between tools, products, and services which vendors would supply to that community. Guidance is offered on the key factors for deciding whether or not to embark upon a profiling exercise and a process outlined for how to proceed with such an activity. In sub-section 2.2.2 'Lessons Learned from Adoption' of the Management Overview in particular, highlights the fact that adoption of the specifications often entails a selection of the specifications to adopt, some changes to the information model for these specifications and some adaptation (e.g., language, vocabularies) to serve a particular community. The available documentation for these profiles is highly variable and rarely captures the process by which they were derived. The Application Profile Guidelines makes explicit such a process in this Management Overview and offers further guidance in this, the Technical Manual, on how an application profile should be developed and documented. Conformance issues around an application profile are briefly discussed, as are technology and implementation issues beyond the scope covered by the specifications.

The document is offered as a guideline, based upon the experience of a number of user communities in adopting and implementing the specifications in the hope that their experience will be useful to others facing the same issues which they have had to work through with their users and suppliers. Nothing in this document is mandatory - ultimately the choices are made by implementers and the users of their offerings. However, the document does capture a viable process for helping vendors more closely meet the needs of a community, without necessarily breaking broader interoperability and maximizing the use of implementations against one or more base specifications.

Having opted to create an application profile in the manner prescribed, achieving interoperability across implementations of that profile is still dependent upon a number of independent, ongoing factors, not least:

• Consistent interpretation by implementers of the application profile;
• Consistent use of vocabularies by the information sources;
• Consistent use of the information by users of the information.

The paper describes in detail the operations that are available to adapt a specification given by a data model and an XML schema. All these operations may affect interoperability. It is acknowledged that there are situations where nevertheless the need to deliver community-specific data and services in conjunction with data and services of general relevance requires profiling of a specification. In these situations, the current paper will provide information about the consequences of particular profiling decisions with respect to interoperability and it may contain alternative solutions.

The paper does not handle profiling of specifications of dynamic behavior of systems As far as formal specifications are concerned, only the profiling of XML data model bindings is within the scope of this paper. It is intended to handle specifications of services, of runtime behavior, or of specifications given in UML in a later version of this document when sufficient experience has been gained. The paper also does not consider domain profiling, i.e., the simultaneous adaptation of several specifications and their interconnected use. Moreover, this paper does not discuss secondary profiling, i.e., the further adaptation of an application profile, though many of the issues discussed below are also relevant in this case.

1.2 Definitions

1.3 References

2. Developing an Application Profile

The development of an application profile begins with the establishment of a community of shared interests that can identify the need for an application profile and support its development and maintenance. The community needs to define itself as an entity and create an agreement between its constituents.

This community, once established, looks at the requirements of its members, both in terms of existing systems and processes and its future needs. It also needs to take account of the specifications (and existing application profiles) available to it.

Once requirements have been gathered, there needs to be a process of analysis and synthesis, where the community produces models of its domain and identifies gaps in available specifications. It may also develop a reference architecture model to place the specifications within a system design context.

At this point, the community has the information with which to make the decision whether or not it is appropriate to create a profile. It also needs to consider other practical issues, such as the estimated costs and predicted benefits of creating the profile, and also the opportunities, risks, and strategies associated with the take up of a profile by the implementation community.

If the community decides it is appropriate to create a profile, it can then make a choice of specifications and/or existing profiles, and begin development of the application profile. During the development process it may be necessary to revisit the requirements and analysis and synthesis phases, to qualify, re-examine, and review their outputs in the light of decision points within the development process.

Finally, an initial application profile is created. Profiles need to be published, ideally in a registry of application profiles, so that other organizations wishing to create profiles can locate and reuse existing work. Where this is not applicable or practical, then the profile should at least be published formally with an official identifier.

This is not the end of the overall process, as this profile still needs to be maintained, and the community must support its implementation community.

This whole process is encapsulated in the diagram in Figure 2.1.

2.1 Types of Application Profile

For the purposes of these guidelines, we define two types of application profile.

A Data Profile consists only of a profile of an information model of a static structure. Sometimes such a model is called a "Conceptual Data Schema".

A Bound Data Profile consists of a profile of both an information model and a binding for a static structure. The binding may be to XML, RDF, or some other technology. It is also possible that a Bound Data Profile will contain a single information model profile but more than one binding profile. In the current paper only profiling of a single XML binding is under consideration.

Section 3 of this document describes how to create both a Data Profile and a Bound Data Profile.

Each information model describes a set of documents that are compliant with this model. When two applications interoperate, they exchange documents which have to be compliant with their respective information models. In the elementary case of a single information exchange one of the systems acts as a sender (or writer) of the document and the other acts as a receiver (reader) of the document. In the current context it does not matter by which methods the document is transmitted - it may be by file transfer with or without human intervention or as payload of a service message exchange.

We assume, subsequently, that the set of documents which an application can read or write is described by a bound or unbound data profile. We note that a system may use different data profiles for reading and writing. For example, it may read a larger variety of data than what it writes itself. Therefore, we shall distinguish between the read profile and the write profile of an application. In fact, an application may use several read and write profiles in order to interoperate with a variety of other applications but we shall abstract from this since it does not affect the following considerations, i.e., we consider for each application A at most one read profile A.ReadProfile or write profile A.WriteProfile.

For each data profile DP let DP.Data denote the set of data that are compliant with the profile DP. In order to interoperate, each document that can be produced by the sender must be digestible by the receiver. With this notation for guaranteeing interoperability when sending data from a sender Sender to a receiver Receiver it is necessary that Sender.WriteProfile.Data is a subset of Receiver.ReadProfile.Data:

Different data profiles describe different sets of data. A data profile DP1 is said to be restrictive with respect to another data model DP2 if all data which are compliant with DP1 are also compliant with respect to DP2 , i.e., DP1.Data is a subset of DP2.Data. In this case we also call DP2 extensive with respect to DP1. In the interoperable case described above, the profile Sender.WriteProfile is restrictive with respect to the profile Receiver.ReadProfile and Receiver.ReadPofile is extensive with respect to Sender.WriteProfile. If two data profiles are not restrictive or extensive with respect to each other we call them incompatible.

Now let us consider what may happen when data profiles are derived from a base specification. Each specification has its data model which is considered as a data profile of itself with no changes made.

First of all, we observe that using only data profiles that restrict the base specification data model does not ensure interoperability:

However if the read profile of the receiver is extensive with respect to the base specification data model but the write profile still restrictive, data can be sent and received successfully:

This is the recommended practice, i.e., applications should be capable of reading at least all data which are compliant with the base specification data model but they should write, at most, a subset of the data permitted by the base specification.

In this case, each application which is write-compliant with respect to IM1 is also write-compliant with respect to IM2 and each application which is read-compliant with respect to IM2 is also read compliant with respect to IM1. Note that an application which is compliant with one of these information models will not necessarily be compliant with the other model.

An application is said to be write compliant with a data profile if it produces only data that are compliant with this profile, i.e., its write profile is restrictive with respect to the data profile. The application is called read compliant with a data profile if it can read all data which are compliant with this profile, i.e., its read profile is extensive with respect to the data profile. Sender and receiver will only interoperate if there is a data profile such that the sender is write compliant and the receiver is read compliant with this data profile. We call an application compliant with a data profile if it is read compliant as well as write compliant with respect to this data profile.

2.2 Bound Data Profiles and Categories of Modifications

A bound data profile has a data model and a binding for a static data structure. Bound data models are usually derived from specifications which have an information model as well as a binding which defines the structure of the compliant data. In this document we confine ourselves to the case where the binding is given in the base specification by an XML schema, referred to subsequently as the base schema. An application profile must clearly state which base specification it is based upon, including all applicable version references.

Depending on the particular base specification and the intended use of the profile, the profile created may need to be based either on the information model or the binding supplied for the base specification. For example, when creating a profile of the IEEE LOM standard for use internally by a system, it may be necessary to only profile the information model of LOM, and create a new binding. In other cases it may be more advisable to create a profile of both the information model and the binding, especially where the profile is being used for interoperability between parties.

Where base specifications contain variants, it should be noted in the profile which variant has been used. For example, the IMS Learning Design specification has three variants: "Level A", "Level B" and "Level C". When creating an application profile of Learning Design, it should clearly be stated which level the profile is based upon.

A profile is derived from a base specification by applying a set of modifications. Subsequently, this paper will discuss a number of possible modifications in detail. For now we observe that we can distinguish three categories of modifications, depending on their effect and on the way they can be encoded in the application profile.

1. XML Schema modifications concern the structure of XML documents and can be expressed in a modified XML schema. Making an optional element mandatory is a schema modification;
2. XML non-Schema modifications concern the structure of XML documents but cannot be expressed in a modified XML schema. All modifications that depend on the concrete situation in an XML instance document are of this category;
3. Additional constraints. These modifications do not concern the structure of XML documents. For example the request that a certain file must exist at a certain place in a data package is of this category.

More examples will be given below. The partition of the modifications into these categories has consequences for the possibilities to ensure compliance and thus to support interoperability.

For XML schema modifications, which can be manifested in a derived XML schema, there is a number of validating XML parsers available which can check automatically that a given XML document has a structure as requested by modifications of this category. It is recommended that application profiles should use XML schema modifications if this is possible. The analysis of a number of application profiles suggests that most modifications can be described as XML schema modifications.

XML non-schema modifications require the development of particular test tools. XML technology supports such developments well. We mention XSLT and Schematron here. The analysis of a number of application profiles suggests that only very special cases require XML non-schema modifications.

Additional constraints often arise from the modification of conditions which are stated in the information model of the base specification but not in the base schema. Checking the conditions set up by these modifications requires ad hoc software development. The analysis of a number of application profiles suggests that such modifications occur frequently but with few variations only.

2.3 The Smallest Permitted Length and Related Restrictions

For some specifications, the information model requires that for specific elements of string type compliant systems should permit values of a specified length N at least. This is not a condition on the structure of compliant data but a condition on compliant systems. In fact, this minimum permitted length restriction defines two different conditions for a data profile being extensive or restrictive, depending on whether it is used as a read or write profile.

Restrictive read profiles must have a maximum length restriction for these elements which is either unbounded or has a value greater than or equal to N. However, for a restrictive write profile the maximum length restriction for these elements should be less than or equal to N in order to make sure that systems compliant with the base specification use the written data correctly.

Similar considerations apply to the smallest permitted number of elements in a list when specified in the base specification.

2.4 Extending Specifications in Application Profiles

A major motivation for profiling a specification is the lack of particular data fields which are needed for keeping information which is relevant for a specific community.

Uncontrolled extension of an information model, e.g., by adding at arbitrary locations items to the information model or including structures from other base specifications, is strongly discouraged as this will almost certainly break compliance with the base specification. Such extensions greatly reduce the chance of implementations against the base specification from being able to support the profile. Many base specifications, however, define permitted means of extension, and wherever possible these should be used, as this reduces the risk of people adopting your profile creating instances that are invalid against the base specification.

Permitted means of extension have in most cases the form of wildcards, i.e., these are specific places in the information model where anything can be inserted and the document is still considered to be compliant with the base specification. Therefore any profile being more specific, i.e., specifying what is allowed at these places, will lead to a restrictive profile, even though it introduces new elements. The recommended behavior of systems is that they should tolerate all possible uses of the extension points in their read profile but they may confine to a particular usage of extensions in the data they write, i.e., they may use a restrictive write profile.

It is also possible to create a profile which implicitly extends a base specification - for example, by adding items to a controlled vocabulary or by extending the permitted length of a text item or by casting a restricted type into a less restricted one (e.g., from an Integer to a String, or from an Integer to a Real). In contrast with the use of extension points just described, these are indeed extensive profiling operations. Such operations are damaging with respect to read compliance with the base specification and hence are strongly discouraged for write profiles.

By way of comparison, operations which further constrain the permitted values are generally acceptable for write profiles - such as imposing a vocabulary on a text string or further restricting the permitted length of a text item or casting a restricted type into a more restricted one (e.g., from a Real to an Integer) or applying a restricted range of values of a particular type (e.g., applying an integer range such as [1, .., 10] to an Integer value). In all of these cases, an instance of the information model would still validate against the base specification and hence could be read by tools that implement the base specification.

2.5 Excursion: Translations, Vocabularies, Localizations, and Mappings

Sometimes it may seem desirable to use data structures or names which differ from those described in the specification. Inevitably, systems which implement the base specification will not be able to read or write data which use these new items. Therefore, such modifications should not be made lightly.

When considering an application profile for a community using a language other than US English, it is generally preferable to do a language translation of the information model of the base specification, thereby creating a new information model to use as the control document against any subsequent application profile. The translated information model should introduce no changes to the structure of the information model, the mandatory/optional status of the elements, nor should it introduce new elements or eliminate existing ones. Translations should be confined to translations of the documentation and to translations of controlled vocabularies. It is recommended to add parts to the documentation which describe the meaning of the translated phrases, provide recommendations for their usage. Translations should provide mappings which relate translated phrases with their US English versions.

Typing and translations of controlled vocabularies should be equivalent to those in the original information model. If a straightforward translation is possible it may be worth investigating whether it is possible to use the base specification and to extend instead the tools which process the data by some wrapper which does the required translations when data are read or written.

Controlled vocabularies occur in specifications either in line (as part of the specification in the form of an enumeration of admitted phrases) or referenced (as a reference to an external vocabulary). In the first case, translations must replace the phrases in the specification with their translations. Systems which are read compliant with the base specification will not be able to process data which are built according to the translated specification. However, the provided translation mappings may be used to implement a conversion of data to their US English variant and conversely.

If controlled vocabularies are referenced only in the base specification, any language-specific community may agree on the usage of a specific vocabulary. Specifying such a vocabulary can be done in a restrictive profile. Therefore systems which implement the full (i.e. vocabulary-independent) base specification in their read profile will be able to process data using the specific vocabulary. It is recommended to provide mappings between phrases in different vocabularies in order to facilitate the reuse of data. Note that the use of referenced vocabularies has - in comparison with using inline vocabularies - the advantage that systems can be adapted to different languages without requiring translations of their input data. The IMS VDEX specification provides more information on the use of referenced vocabularies.

Having derived an equivalent information model in the target language, any application profile should strive for compliance with this language-specific information model in order that it can exploit language-specific implementations against the localized information model.

By their nature, translations, localizations, and mappings differ from the profiling modifications since they not only modify a specification but give addition information that can be used to convert data so that they become compliant with either the base specification or the application profile.

This conversion need not be determined uniquely if the mapping defines only a relation between values but not a function. For example, assume that in the base specification a scale of grades A,B,C,D is used where, in a certain domain, grade A entitles for enrollment in a course and C and D are considered as insufficient for the continuation of a study. In another community, grades 1,2,3,4 are used and grades 1 and 2 entitle enrollment while grade 4 is insufficient for the continuation of the study. Then it makes sense to map A to 1 and 2, B to 3 and C and D to 4. Note that a combination of translation and re-translation will usually not result in the original data if the mapping is not one-to-one. In order to care for situations where some values cannot be mapped at all, translated profiles should allow an indeterminate value like undefined.

Except for the most straightforward cases, best practice documents for application profiles should explain the intended usage of the translated vocabulary and the rationale of the mapping provided (if any). Then a correct usage of the vocabulary will be crucial for the semantic interoperability of systems implementing the application profile.

Adding to or removing items from a vocabulary needs to be done with care. If the vocabulary is defined inline in the specification as a list of permitted items, adding or removing items is an extensive respectively restrictive modification. But the situation is more complicated if the vocabulary is given in the base specification by reference only. These referenced vocabularies cannot be changed by a modification of the base specification since they are not part of it. Instead, a new vocabulary, identified by a new URI, should be provided and referenced by the application profile. In order to be restrictive, the new vocabulary must not add new items and must use only identifiers which have been used in the vocabulary referenced by the base schema. Also, the type of the vocabulary should not be changed.

In order to avoid any danger of confusion it is recommended to reference a new vocabulary whenever any vocabulary change is made and to provide vocabulary mappings to support the development of conversion utilities.

3. Creating Application Profiles of Data Specifications

3.1 Defining an Information Model

For each specification utilized that involves a data model of some description, you need to define precisely how that model needs to be adapted to meet your requirements.

There are a number of operations that can be used for adapting an information model, each with implications for interoperability within your community or application, and for retaining compatibility with the wider world.

For each operation mentioned below, guidelines are given on how to perform the operation, what the benefits and implications are for your profile, and how the intent of the operation can be expressed. Ways to formally encode the intended modifications in XML will be explained in the next section.

Although not many people understand formal notation, the precision of meaning provided by a formal expression language is highly beneficial when developing test harnesses, where ambiguities in English and other natural languages can prove problematic. It can also be useful for automatically generating bindings for various technologies, such as XML Schema, Java, or SQL.

Because not everyone understands XML, it is important to always provide a less formal description of each profiling statement using natural language. The XML binding described in the next section provides fields for the application profile and for the individual modifications to add explanations or a documentation of the rationale in various languages. It is recommended to fill these fields and to generate a human readable documentation of the application profile from these annotations.

The modifications identified below are split into the categories explained in the last section:

• Restrictive Modifications - instances of the profile can be used by tools and products that correctly implement the base schema in their read profile. The base schema can further be used to export data outside the immediate target community. It is recommended to use only these modifications in write profiles of applications;
• Extensive Modifications - instances of the profile schema may well no longer validate against the base schema and hence tools and products may require some customization to use instances to the resulting profile. Data will also need additional handling to achieve exchange with external communities. These operations are strongly discouraged for use by write profiles and should be adopted only if the communities need cannot be addressed by any other means. They are, however, of no harm in read profiles of applications. Applications using extensive modifications in their read profile may well use all instances of the base schema;
• Incompatible Modifications - these operations break interoperability with the base specification completely and should not be undertaken in any circumstances. Note that also the simultaneous usage of restrictive and extensive modifications will result in an incompatible profile.

3.1.1 Restrictive Modifications

3.1.1.1 Modifying the Size of a Text Item

Method: Specify a size constraint for an item in the specification, either:

• Lowering an existing maximum text length constraint; or
• Increasing an existing minimum text length constraint; or
• Adding a constraint to an unconstrained String-type item.

Benefits: Constraining text lengths prevents problems with relational databases storing data and allows relational schema to be developed with less ambiguity. Specifying minimum text lengths may also be desirable in some circumstances.

Implications: By constraining allowable sizes you run the risk of values of items created to the original specification containing illegal String lengths for your application profile, resulting in either truncation or errors when read into a system conforming to your profile.

Example:

3.1.1.2 Modifying an Item by Prescribing the Use of a Controlled Vocabulary

Method: For an item in the specification:

• If no vocabulary is defined in the specification but the usage of a vocabulary is foreseen specify a particular vocabulary for your domain;
• If a vocabulary is defined in the specification a more restricted vocabulary may be used;
• If an item is defined in the specification only to have a string value a list of admitted values may be prescribed.

Benefits: Maintain the benefits offered by the use of vocabularies, but with values that are relevant to your community.

Implications: Restricting a vocabulary by removing items risks non-interoperability with existing applications and data that conforms to the specification. However, it will not prevent data created with your profile to conform to the original specification. Using references into external vocabularies instead of specifying a fixed list of phrases makes it easier to adapt existing systems. It is also to be preferred if a multilingual community is to be served. The IMS VDEX [VDEX, 04] specification provides more information on the recommended use of controlled vocabularies.

In any case, items from a controlled vocabulary should only be used if their meaning is sufficiently clear in the community addressed. They should not be used with a different meaning. Abusing an item from a controlled vocabulary to describe "something similar" may result in semantic non-interoperability, misinterpretation, and misbehavior which cannot be detected by automated tests and which may therefore remain uncovered for a long time.

Example:

3.1.1.3 Modifying an Item's Data Type

Method: Specify a new, more restricted data type for an item in the specification, such as stating that an item of type Real in the specification should instead be an Integer in your profile.

Benefits: In some cases, greater precision may be necessary for specifying an item than is possible using the default type given in the specification, for example if you require an item to only contain whole numbers and no fractions, but the default type is a Real or String. In such cases, recasting the type may be more efficient than applying a range of complex restrictions to achieve the same effect.

Implications: In cases where a type is being changed in a way which restricts the range of values, such as from a Real to an Integer, this will have the effect that instances conforming to the profile can still be cast to conform to the specification. Note that it is only important that the modification restricts the lexical space of the item's original data space. Their value spaces, i.e. their interpretation according to the data type may well be incompatible without interfering with interoperability.

Example:

3.1.1.4 Refining an Item by Clarifying its Meaning

Method: Provide additional narrative for an item explaining its specific interpretation for the application profile. This also can include providing localization of descriptions and providing assistive text.

Benefits: By augmenting usage descriptions provided in the specification it makes the use of the item clearer and less ambiguous and can reduce errors in interpreting the specification for the local context.

Implications: The refinement you provide may actually change the meaning of the field if it strays too far from the given description. This could cause existing tools to use the data incorrectly. If a refinement does this then it becomes a redefinition of the item, and it may be worth considering using an extension instead, as redefining existing items is strongly discouraged.

Example:

3.1.1.5 Changing the Scale or Precision of a Numeric Item

Method: For an item in the specification that is a Real number, alter the allowed scale and precision to suit your profile; either alter the precision alone, or as a factor of scale.

Benefits: Restricting the precision of a Real number to an agreed number of places reduces the likelihood of rounding errors. Specifying both scale and precision for a Real number also makes it possible to directly relate the possible values of instances to fit within database structures defined in terms of both scale and precision.

Implications: Instances conforming to the profile may be subject to rounding and possible error if used in processes that conform to the original specification.

Example:

3.1.1.6 Restricting the Range of a Numeric Item

Method: For an item in the specification that is an Integer or Real number, restrict the range of valid number, either by creating a new range constraint or by altering an existing range constraint.

Benefits: Restricting the range of a number ensures it falls within values which are meaningful in context. For example, if numbered grades in your educational system range from 25-120, then requiring grade values to fall within this range helps to ensure only valid grades are entered.

Implications: While all instances of this item within your profile will also conform to the specification, the reverse is not true.

Example:

3.1.1.7 Mandating an Optional Item

Method: For an item in the specification that is indicated to be optional, require that for your application profile this item is mandatory.

Benefits: Allowing optional items hampers interoperability, as different systems may end up choosing different sets of optional items to support. By mandating an item you can guarantee that systems will support an item, and that data will always contain that item, reducing the number of possible data combinations that need to be supported.

Implications: Tools that are based on the profile may not be able to read instances constructed to the original specification as they may omit the item that the profile has mandated. In case of attributes you should consider to specify a default value in the application profile so that systems compliant with your application profile may still read instances that omit the mandated attribute.

Example:

3.1.1.8 Requiring an Optional Item to be Mandatory Under Certain Conditions

Method: Require that an item defined as optional in the specification must be used depending on the values of other items.

Benefits: Often the value of one item affects another, so it is useful to constrain an application profile to take account of these effects.

Implications: Tools that are based on the profile may not be able to work with instances constructed to the original specification as they may omit the item that the profile has mandated.

Note that this modification is fundamentally different from the modifications described previously since it is dependent on the situation in the particular instance document which is not known at the time the application profile is written. These conditional modifications cannot be captured in a modified XML schema. However, they can be expressed in XML in the XML binding of an application profile as described in the next section. Other tools like Schematron rules can be used as well.

Example:

3.1.1.9 Excluding an Item

Method: Require that an optional item in the specification should not be used for your profile. You can require it to be not present at all or require that it must always be set to a null or empty value.

Benefits: If an item has no meaning in the context of your profile, then excluding it simplifies the overall model and prevents the item being used inappropriately.

Implications: If the item is mandatory in the specification, than interoperability is no longer possible between profile and specification-conformant systems - the modification is incompatible.

If the item is optional in the specification, then instances conforming to the profile are still conformant to the specification; however, tools that are based on the profile may not be able to work with instances constructed to the original specification as they may include the item that the profile has excluded. Instead of excluding a required item, it is recommended to require the usage of a default value which may be empty.

When a mandatory item is excluded, the profile is incompatible.

Example:

3.1.1.10 Restricting an Item by Mandating a Controlled Vocabulary

Method: Mandate for an item a specific controlled vocabulary of acceptable values within the application profile.

Benefits: Restricting the number of possible values improves interoperability by reducing the number of interpretations required to be supported for the value of the item.

Implications: Existing data or systems not specific to your community can use values other than the ones specified by your vocabulary, so this will affect interoperability; however, tools and data constructed for your profile will still meet the requirements of the broader community, provided that you are providing a restricted vocabulary for an existing open item, such as a String and not changing a vocabulary (see below).

Example:

3.1.1.11 Restricting a Text Item by Specifying a Pattern

Method: Specify that a text item must conform to a pattern, such as defined using a regular expression.

Benefits: This ensures that all such entries are in a format that can be readily used without being re-interpreted by conformant systems.

Implications: While all instances of this item within your profile will also conform to the specification, the reverse is not true.

Example:

3.1.1.12 Requiring a Set of Items to Appear in a Particular Order

Method: For a set of items, specify the order that they must appear in within instances.

Benefits: By specifying an order for items, it may be possible to make implementation easier, or better optimized for performance.

Implications: In some binding technologies it is not always a simple matter to ensure the ordering of items, or that ordering will be preserved during the import and export process, making conformance more difficult. Notably the XML binding described in the next section does not permit modifying a choice of elements to become a sequence. In some cases the intended effect may be achieved nevertheless using conditional modifications.

Example: Where a base specification defines "groups" and "members" with associations between them, requiring a "group" to occur before any of its members means that the structure can be parsed line-by-line, rather than having to hold "members" in memory until their associated "group" is reached. A condition in the profile may test whether each "member" element is preceded by a "group" element in an instance document and may impose a type conflict otherwise.

3.1.1.13 Requiring an Item to Have a Particular Default Value

Method: Specify that, where an item in an instance does not have a value, that a particular value defined within the profile should be used.

Benefits: You may need to ensure that an item always holds a valid value, even if it is the default, so that systems operate in a known fashion when encountering blank items.

Implications: If the item already has a default value in the specification, and you are requiring a different default, then this will have interoperability implications for any instances that do not supply the value, as they will be treated differently by systems conforming to the profile than from systems conforming to the specification.

Example:

3.1.1.14 Requiring an Item to be Expressed in a Particular Human Language

Method: For an item in the base specification, require that the content of that item be expressed in a particular human language.

Benefits: You may want to require that human-readable information held in an instance is available in languages specified by your community.

Implications: There are no specific interoperability implications, although instances conforming to the specification may require translation before they would interoperate properly with profile-conformant systems.

Example:

3.1.1.15 Requiring Everything within a Profile to be in a Particular Human Language

Method: Using some means of identifying exceptions, require all text items within the profile to have an expression in the specified human language.

Benefits: You may want to express language constraints globally.

Implications: There are no specific interoperability implications, although instances conforming to the specification may require translation before they would interoperate properly with profile-conformant systems.

Example: This is typically expressed using a statement such as "The default language for all items is English unless stated otherwise".

3.1.1.16 Referencing or Including Items or Structures from Other Data Models

Method: Within the information model for the base specification, include (or reference) parts of another information model; for example, from another specification. Many specifications contain extension points where you can easily add additional items from other specifications or from your own information model. The simultaneous modification of several specifications is called domain profiling. It goes beyond the scope of this document.

Benefits: In some cases, information you need to represent is not present in the specification, but is part of another specification. By including this information you can meet the requirements for your community while also adhering to standards and specifications rather than constructing your own extensions. A typical example is the addition of meta-data structures.

Implications: The same warnings apply to inclusion of other models as to the construction and placement of extensions - if the base specification does not provide a mechanism for including additional data types, or you decide to incorporate the structures in a different way than is advised by the base specifications, then this will result in interoperability problems. When extension points are used, instance documents will have to include the location of the definitions of the additional elements. The recommended behavior for applications is to store extensions which they find in imported instance documents at extension points. If the same document is re-exported, the extension information should be preserved.

Example: In IMS Content Packaging, there are meta-data items which typically are used as containers for structures included from either the IMS Meta-Data or Dublin Core meta-data specifications.

3.1.1.17 Restricting the Levels of Nesting of a Recursive Item

Method: For an item that has a recursive structure (that is, it contains instances of itself, like a self-join in a database), restrict the levels of nesting allowed. This can be expressed in an application profile by making the usage of the element in question dependent on a condition which tests that the level of nesting of the item in question in instance documents does not exceed the specified limit.

Benefits: At its most extreme, this allows the profile to insist on a certain degree of structural homogeneity amongst instances, such as requiring instances to be constructed in an ontology-like fashion (as flat lists of items joined by explicitly typed relationships) rather than in a hierarchic fashion with implied relationships. In other cases, restricting nesting levels provides developers with a fixed boundary against which to code, and may reduce the overall memory footprint and threading requirement for applications supporting the profile.

Implications: Restricting nesting levels will result in instances conforming to the profile also conforming to the specification, but not necessarily the reverse.

Example:

3.1.1.18 Restricting the Target of an Association by Type

Method: For an item that can contain a reference to another item, such as a pointer or index reference, restrict the type of item that can be the target of the reference. This is an additional constraint modification.

Benefits: Sometimes a specification will support a wide range of associations, only some of which are applicable to your community or usage context. By restricting the types of associations you reduce the range of possible behaviors that systems will have to interpret, making implementation easier.

Implications: Restricting associations means that instances that conform to your profile will also conform to the base specification in this regard, however the reverse is not necessarily true, and valid instances of the base specification may not conform to your profile or be usable in systems that support it.

Example: In IMS Content Packaging, an Item contains a reference that can be made to point to either a Resource or a Manifest (a "submanifest" in IMS CP parlance). An application profile may be created that prohibits the use of submanifests, and so restrict an Item reference to only point to a Resource.

3.1.1.19 Restricting the Structure of a Data Package

Method: If data are exchanged not as a single file but as a set of files, a profile may impose additional constraints on the structure, content, or packaging of this data package.

Benefits: Being stricter with the structure, data formats or packaging formats of data packages simplifies the implementation of software that can read these packages. Also, data packages that conform to the profile can be read by systems which fully implement the base specification.

Implications: Valid instances of the base specification may not conform to your profile or be usable in systems that support it. However, it may be possible to provide filtering software which converts data packages from other formats into the format requested by the application profile. The application profile should document how the information found in other base specification conformant data packages should be encoded in the more restricted way.

Example: A profile may request an IMS Content Package to be delivered as a zip file and that each data file in the package must be referenced by a resource item.

3.1.2 Extensive Modifications

Extensive modifications extend the set of admitted data. Consequently, applications which conform to the base specification in their read profile may not be able to read data which conform to the application profile. On the other hand, the use of extensive modifications is not critical in read profiles of applications. Note that the use of extension points of the base specification (mild extension) is a restrictive modification since it restricts the arbitrariness of items which can be used at these points. The introduction of new elements at other points (wild extension) will be in most cases neither a restrictive nor an extensive but an incompatible modification. If there is no extension point available where needed, it should be explored whether instead an available extension point can be used. If even this is not possible, new items should be added at the end of existing item sequences, hoping that future versions of the base specification may add the required extension point later.

3.1.2.1 Making a Mandatory Item Optional

Method: For an item in the specification that is defined as mandatory, allow anyone implementing your profile to treat that item as optional.

Benefits: If an item mandated by the specification has no meaning (or an ambiguous meaning) in your application context, then it may be beneficial to allow it to be optional.

Implications: Allowing mandated items to be optional means that instances conforming to your profile are unlikely to be interoperable with systems and instances that conform to the original specification, although interoperability in the other direction (consuming instances or interoperating with systems conforming to the specification) is not likely to be affected. It is worth considering whether the specification you have chosen is the one appropriate to your needs if you have to utilize this strategy, as it is generally only those items that are critical to its function that are mandated in a specification.

Example:

3.1.3 Incompatible Modifications

3.1.3.1 Altering the Relative Location of an Existing Item

Method: For an item in the specification, define in your profile a new location within the model for this item.

Benefits: There is no real benefit to this; perhaps all except one attribute of a larger structure is being excluded and rather than have a sparse structure you have decided to aggregate the remaining item into another part of the data model for ease of readability.

Implications: Altering the data model in this fashion will almost certainly break interoperability between profile and base specification.

Example: There are no obvious examples of this strategy.

3.1.3.2 Creating a New Element that Mimics the Semantic Intent of an Existing Element

Method: Create an item in the profile for something that already exists in the specification.

Benefits: There is no real benefit to this - possibly the intent may be actually to modify the multiplicity or length of an existing item, or otherwise avoid some of its restrictions, but for some reason this is not being done explicitly.

Implications: Having multiple items with the same meaning, but in different locations with differing names or other syntax, is problematic in terms of interpreting what is correct conformant behavior. If the item in the specification is unsuitable, you should consider profiling that item rather than duplicating it.

Example: An example may be to add an additional "ExtTitle" item, with a greater allowed length than the "Title" item defined in the specification.

3.1.3.3 Changing the Meaning of an Existing Item

Method: Change the meaning of an item in the specification to suit your profile.

Benefits: The intention of this action is to effectively extend the specification without using an extension.

Implications: Changing the