SchemaProf is an XML schema profiling tool that is used to localize XML schemas, typically the XML binding of a specification or standard. This schema is modified to reflect the specific usage of the specification by a community. The result of this process is a community application profile.

An application profile contains only the differences made to the base schema and is intended to be used in combination with the base schema.

During the work with XML schema profiling it was noticed that most specifications, define data structures and constraints in text documents. XML bindings of the specification in form of XML schemas can not express all constraints of a specification. Therefore, starting with SchemaProf v4.0 the concept of additional constraints (AC) is introduced. Additional constraints are stored in an XML file that are considered by the other TELCERT tools and aid in producing specification or profile compliant XML documents.

SchemaProf 4 can be used both for constraint authoring and for localizing (profiling) of XML schemas. In constraint authoring an AC file for an XML schema is produced. In schema profiling that schema is localized according to the community need, the schema can be annotated and a link to the AC file is established.

The additional constraint file and application profile can then be used by the other TELCERT tools:

Schema Transform Tool: merges the modifications made into a new XML schema where possible and saves unmerged modification in extra files (available as plug-in).
Reload CRT: helps in converting and editing XML documents to produce profile compliant documents.
TELCERT Test System: used for self-testing and certification of XML content against application profiles.

In SchemaProf v4.5 the support for our profile repository is introduced. The intention of the profile repository is to foster and support the communities in profiling their specifications by providing a platform for the open exchange of application profiles. Looking at existing profiles and finding people working with the same specifications are only two examples of how you can benefit from our repository.

Using the profile repository is free, no charges are taken. The main functionality introduced at the current stage is:

§ SchemaProf can now save all profile related files into a single ZIP-file, additionally to saving into a directory structure as before. This simplifies the exchange of profiles via email and the upload to the profile repository.

§ SchemaProf includes the Profile Repository Manager that allows you to upload you profiles directly into our profile repository via web services.

§ Profiles are enriched with extra metadata information prior to uploading to the repository, mostly Dublin Core metadata. Some metadata is extracted from you profile annotations. This metadata is needed to search for related profiles.

§ Searching the repository for related profiles is supported through the search client tool available on the repository homepage (see below).

Detailed information on the profile repository and how to use is can be obtained in the section Application Profile Repository of this manual and on the profile repository homepage http://iwm.uni-koblenz.de/profiles/. Feedback and suggestions for improvement are of course welcome and should be supplied to the contact given on the repository homepage.

1. SchemaProf User Interface

The SchemaProf user interface is designed in a classical Java software layout. It starts with a splash screen that shows the software logo and current version number while loading the program in background.

The main program window is divided into these main areas:

1. The menu bar gives access to the top level functionality.

2. The toolbar provides quick access to most often used functions.

3. The selection tabs switch between schema modifications and constraint, and group the schema components into top level categories.

4. The navigation tree shows the schema structure and components and allows the selection of components for modification and annotation.

5. The working area shows information on the currently selected element and allows the user to apply operations on that element.

6. The status bar shows the operation mode and compatibility level.

(5) Working Area

(4) Navigation Tree

(6) Status Bar

(3) Selection Tabs

(1) Menu

Figure 1: The SchemaProf main window layout

For many operations pop-up dialog boxes will open to request the information needed from the user, some of them guide the user through several dialogs with a wizard interface.

1.1. Menu bar

The SchemaProf menu provides access to the following menu items:

File Menu

New…	Starts a new profile or constraint file, based on an XML base schema to be specified by the user. Prior to that SchemaProf will ask the user to save any unsaved changes to the current profile.
Open…	Open an existing profile or constraint file.
Save	Save the current file. If the file name is not specified the user must enter it now.
Save as…	Save the current profile or constraint file into another file or directory.
Close	Close the currently opened file. If latest changes have not been saved, SchemaProf will ask to save or discard the changes.
1 <filename> […]	The file history that shows the last five files that have been opened. Select any of the files to open it directly.
Quit	Quit SchemaProf. If latest changes have not been saved, SchemaProf will ask to save or discard the changes.

Manager

Type Manager	The type manager gives an overview over the user defined type of the current profile and allows deletion or editing. A type is defined globally and may be used at several positions of a profile.
Condition Manager	The condition manager gives an overview over the user defined conditions of this profile and allows deletion or editing. A condition is defined globally and may be used at several positions of a profile.
Namespace Manager	The namespace manager is the place where you can set the target namespace for your profile. It also gives an overview of all namespaces used in the profile.
Profile Manager	The profile manager shows all the profiles referenced by the current profile. This is important for domain profiles.
Constraint Manager	The constraint manager gives an overview of the constraint file used and allows adding or removing constraint files.
Profile Repository Manager	This gives you access to the profile repository. Here you can upload your profile to the repository and make your repository settings. (See http://iwm.uni-koblenz.de/profiles/ for details on the repository.)

Plugins

SchemaProf has a plug-in interface to allow specific extension to the program. Which plugins are available depends on the plugins that are found in the plug-in directory that can be specified in the preferences. By default the following plugins are included in the releases or available on the SchemaProf website.

Howto	Demonstrates and explains the plug-in interface.
Pretty Printing	A simply pretty printing function that is useful to document the changes made to the base schema in a table.
Schema Transformation Tool	This plug-in is provided within the Telcert project by Apple and will merge the changes made to the base schema into a new XML schema and further files. For more information please refer to the SchemaProf website.

Windows

Preferences

Opens the preferences dialog windows that will allow you to change several setting. See section 2.2 Preferences for more details

Help

About

Shows some information about the software, i.e. the software version, license information and contacts.

1.2. Toolbar

The toolbar provides quick access to the most frequently used operations:

	Start new profile or constraint file
	Open existing file
	Save file
	Save file as
	Preferences

Figure 2: The SchemaProf toolbar and menu

1.3. Selection Tabs

The selection tabs give access to the two main areas of work: schema modification and schema constraint editing.

If schema modification is selected, a second row of tabs is displayed grouping the schema components into Elements, ComplexTypes, AttributeGroups and ModelGroups. Each of these tabs shows the schema elements of this type and all of its subelements in the navigation tree. To see the schema structure in hierarchical view, which is possibly the most natural way to start, please select the schema root element under elements.

If the Constraints tab is selected, no second row of tabs is displayed. The navigation tree now shows a simple tree that holds all the constraints currently defined. See section Additional Constraints for more information on profile constraints.

1.4. Navigation Tree

SchemaProf shows the structure of the base XML schema currently in use in a navigation tree on the left side of the program window below the rows of tabs.

The root element of the tree is labelled with the file name of the base XML schema. The type of file currently edited is show by the icon of the root element:

	indicates an additional constraint (AC) file
	Indicates an application or domain profile

The root element expands to folders showing all the elements of the current element type selected by the second row of tabs. Because of references in the XML schemas, sub elements may appear at more than one location of the navigation tree. Especially when selecting the schema root element under ‘Elements’, you will find all of the elements used in this schema.

Unfolding the elements of the tree shows the next nesting level subelements. This way it is possible to descent into the schema until you reach a tree leaf, which is typically a simpleContent or attribute (other types are possible).

Figure 3: The Schema Navigation Tree

The types of elements in the navigation tree are signalled by different icons:

	A compound element that is made up of one or several sub elements, e.g. complex types.
	Click on those symbols to expand or collapse this element in the tree with the details of the element.
	Sequence element: Contains several subelements and the order of the subelements is relevant.
	Choice element: Only one of the subelements may be chosen in the target document.
	Element: Definition of a schema element.
	Simple Content: A tree leaf that will hold a simple type value in any target document.
	Attribute: Definition of an attribute of an element.

Table 1 Navigation Tree Icons

Additionally the cardinality elements (those elements who’s subelements may occur several, i.e. a sequence) show the cardinality of the original definition in the icon, e.g. shows the cardinality one or many elements. See Table 3 for details on cardinality symbols.

1.5. Working Area

The right side of the program windows show the working area.

The content of the working area is adapted according to the element that is currently selected in the navigation tree on the left side. Depending on the type of selected element and whether a constraint file or profile is opened, different actions are available and can be accessed through the buttons on the right side. Others might be disabled or not available.

Figure 4: The SchemaProf Working Area

On top one or more tabs are available. Normally they show the element type of the selected element, e.g. ‘Cardinality Element’. Below, additional information about the element is displayed if available, e.g. element facets or constraint details. The lower part of the working area shows a list of the modifications made to this element when working with the profile, or the constraint definitions when working with constraint files. The buttons on the right are used to add, delete or edit modifications or constraint definitions.

The second tab gives access to the assertions that may be defined through XPath expressions. These assertions are tied to the current element. The assertions are defined in the profile and can only be validated for document instances of the current profile, which can be checked with the TELCERT test system. See section Assertions for more information.

1.6. Preferences

The SchemaProf preferences dialog is available by clicking the toolbar button or selecting the menu entry Windows ► Preferences. The preferences dialog window show three main categories that are available through the tabs on top (see Figure 5).

Figure 5: The preferences dialog window

1.6.1. Global Settings

Compatibility level

SchemaProf can switch between three different compatibility levels. Changing the compatibility levels is done in the preferences window. The levels must always be set by the user.

The compatibility level chosen by the user influences the possibilities offered to the user to modify a base schema. So it is one of the most important tasks to set the correct compatibility level for your application.

When loading a profile that is not compatible to the current level, SchemaProf will refuse to load this profile. SchemaProf does not switch the compatibility level automatically when loading a profile.

Extension Points

SchemaProf provides extensive support for extension point. Despite letting you control the extension points predefined in the base schema through any elements and anyAttributes, it is possible to extend the profile definition format. Enabling this setting gives you access to this functionality. If disable this functionality is hidden for simplicity.

Look and Feel

The ‘Look&Feel’ setting allows switching between some visual appearances of SchemaProf: ‘Windows’, ‘Metal’ and ‘CDE/Motif’ are available. This setting has no influence on the functionality of the program.

Restrictive compatibility is the default compatibility level. The domains of predefined types may only be restricted but not extended. The set of possible document instances based on the resulting profile will therefore be a subset of the set of possible instances of the base schema.
This ensures read compatibility of the application profile with the base schema. Programs capable of working with instances of the base schema will be able to work with all instances of the application profile.

Extensive compatibility allows only extensions of the domains of predefined types but no restrictions. The set of possible instances of the application profile will be a superset of the set of instances of the base schema.
This ensures write compatibility of the application profile to the base schema. Any instance generated (written) by programs capable of working with instances of the base schema will be compatible with the application profile.

Choosing Not compatible allows the user to enter any restrictions or extensions to the predefined types. No checking is done at all on the modifications entered.

A simple example: some profile element is assumed to have 2, 3, 4 or 5 instances in an application. It is therefore specified in the application profile with the cardinalities of minOccurs=2 and maxOccurs=5. The modification that are possible according to the different compatibility levels for minOccurs and maxOccurs are given n the following table.

Compatibility Level	minOccurs	maxOccurs
preset values in base schema	2	5
restrictive	2..5	2..5
extensive	0..2	5..unbounded
not compatible	0..unbounded	0..unbounded

Table 2 Compatibility Level Settings

Please note that despite the compatibility checking, the minOccurs value must of course always be les than or equal to the maxOccurs value. Even with the setting ‘Not compatible’, the program will not accept e.g. the values minOccurs=4 and maxOccurs=3.

For more technical details on the concept of application profiling please look at the IMS Application Profiling Guidelines available at the IMS website:

http://www.imsglobal.org/ap/index.html

Proxy Settings

SchemaProf requires access to all the XML schemas referenced by the current profile and by the XML schemas. Most of them will probably be available through web locations and accessed via HTTP protocol.

To support those network configurations that require the use of a HTTP proxy server, SchemaProf will use the proxy server and port specified if the checkbox “Enable Proxy” is checked.

1.6.2. Internationalization

Starting with version 2.0 SchemaProf is able to switch the display language. To switch the interface language, choose from the languages available at the dropdown box.

The developer team at the Knowledge Media Institute (University Koblenz-Landau) together with the Telcert (http://www.opengroup.org/telcert/) partners currently provide the languages English, German, French and Dutch.

Other languages can be integrated easily and translations are expected to be contributed by the user community. To support this contribution process we are providing a translation tool called ResourceEditor (see Figure 6). It is a simple editor program for the language files. Please look at the SchemaProf website http://iwm.uni-koblenz.de/schemaprof for the ResourceEditor (free for download and usage) and detailed instructions how to use it. On the website you will also find further languages and further information if you want to contribute your translation to the community.

Language files are expected to be given in the language files directory that can be specified in the preferences. Any correct language files from this directory are used by SchemaProf.

Figure 6: The Resource Editor for Internationalization

To be able to support languages like Japanese or Russian that use other characters than the western languages, it may be necessary to switch to a font that contains the required language specific characters or symbols. For this reason SchemaProf also allows the user to choose the font to use.

1.6.3. Plugins

SchemaProf functionality can be extended using plugins. All plugins are expected to be located in a directory the can be set in the preferences. The default directory is the plug-in subdirectory of the download release that includes some basic plugins.

Please note that the plugins themselves may also have their own setting that will be set through the plugins in the menu item Plugins. The latest releases of some plugins are available on the SchemaProf website http://iwm.uni-koblenz.de/schemaprof .

1.7. Help and Bug Reporting

The latest user manual is available online at

http://iwm.uni-koblenz.de/schemaprof/manual/index.html

For offline usage, the user manual is available as PDF or ZIPed HTML pages at:

http://iwm.uni-koblenz.de/schemaprof/documentation.html

No integrated help is currently available. Help pages might be added in a later version, but currently please refer to this printed manual or the online help.

If you find any bugs in the program, please commit them to our Bugzilla system with a detailed description and include the version number of the program. If available please provide your SchemaProf log files from the subdirectory “Log” of your local SchemaProf installation and any other files used (XML Schema, Profiles, etc.). You can attach files to the bug report after committing the initial description. Bugzilla is available at:

http://iwm.uni-koblenz.de/bugzilla/

If you need further assistance please contact us directly via email to schemaprof@uni-koblenz.de. Any feedback and suggestions concerning SchemaProf are welcome under this email address as well.

The version number and license of the program can be found in the about screen that is shown during program start and is available using the menu entry Help ► About.

2. Schema Profiling

This chapter gives information on how to create and edit application profiles. Detailed information on the user interface is given in the previous chapter. This chapter also includes a section on the definition of additional constraints, where constraints are defined for the current application profile.

Another chapter is dedicated to the additional constraint authoring mode of SchemaProf, where additional constraint can be defined as supplement for a base specification. If additional constraint are defined for a base specification, please include specify the appropriate files when creating a new profile. This include a these constraint, while it is still possible to modify and thus disable specific additional constraint.

2.1. File Handling

2.1.1. Creating a new Profile

To start a new profile, use the menu item File ► New… or the corresponding toolbar button. This will open a wizard dialog that allows the user in the first step to choose between creating a new profile or a constraint file. Choose profile here.

Then click the next button to enter constraint files for this specification in the next step. Or choose finish to skip this step. The constraint file can also be added later on through the constraint manager.

Figure 7: Create new profile using the SchemaProf toolbar

Figure 8: New file wizard

Then select the compatibility level you need. If unsure restrictive is recommended. For details on the compatibility level please refer to the section Fehler! Verweisquelle konnte nicht gefunden werden.Fehler! Verweisquelle konnte nicht gefunden werden..

Now choose the base XML schema file you want to profile. This is typically the XSD file of a specification you are using. You may choose a local file by choosing browse… from the drop-down list or enter an URI directly. The drop-down list also shows the last used schema files. Then click Next to set more options or Finish to start profiling.

Having clicked Next gives you the possibility to define one or more constraint files for the current schema. Constraint files can be defined for base schema files as described in section Additional Constraint Authoring. The intention is different then for the constraints defined only for a single profile as described in section Additional Constraints. When all constraint files are defined click Next for the summary screen or Finish to skip the summary and start profiling.

After closing the new file wizard with the finish button SchemaProf will parse the selected base XSD file. This can take a few seconds and includes the reading of any files included or imported by the base schema. When the analysis of the schema file is done, the schema structure is displayed in the navigation tree on the left side of the SchemaProf window.

Now you are ready to begin with the actual profiling work!

The following modification can be made to the schema:

Make global and local annotations to the profile
Modifications to existing types
Creation of new types
Usage of conditions
Use further XML namespaces or Profiles
Add or modify additional constraints

2.1.2. Opening an existing Profile

To open an existing application profile, use the menu item File ► Open… or the corresponding toolbar button. Then choose the file containing your IMS application profiling compliant schema profile from the local file system. This can be an XML file or a ZIP file depending on the format the profile was saved to. The ZIP file is the recommended format, while the XML file (and corresponding directory structure) was the only format supported by earlier versions of SchemaProf.

Loading and parsing of the profile will take a few seconds. The profile structure is then shown on the left side of the program windows in the navigation tree.

Figure 9: Opening an existing profile using the toolbar

Any XSD schema file (base schema, namespaces) or profile XML file referenced in the profile will be searched for locally in the same directory if no other location is specified. This gives you the possibility to: (a) work with locally modified copies of the XSD files specified, and (b) work offline with a local copy of that file in the directory. The XSD files not found in this directory will be loaded from the URL location.

2.1.3. Using the File History

To open the most recent files, SchemaProf offers a file history in the file menu that will show the file names of the last five file than have been opened. This provides quick access to those profiles and avoids having to choose the correct directory first.

Figure 10: Opening a Profile from the File History

2.1.4. Saving a Profile

To save an existing application profile, use the menu item File ► Save to save under the already given filename, or File ► Save as... to save under a different filename or directory. Alternatively you can use the corresponding toolbar buttons.

Figure 11: Save Profile / Save Profile as Toolbar Buttons

You can save your application profile as plain XML file or a ZIP file. The XML format saved the profile and several further files into a directory which should initially be empty. But it is recommended to use the ZIP format that was introduced a few versions before. The ZIP format includes all files and directories of the XML format in a single archive file. This single ZIP file can be opened directly with SchemaProf or be extracted with any ZIP tool. The ZIP file is easier to handle, e.g. to send via email and is the only format supported by the community profile repository.

Figure 12 : Saving a profile under a different name

Please note that a copy of the base schema XSD file and of each referenced XSD file is saved together with the application profile file (in the same directory or ZIP archive).

2.1.5. Closing a Profile

A profile is closed for editing if the user chooses Close from the file menu, or if a new profile is created or opened, or if the user quits the program. Prior to closing the profile, SchemaProf will check for any changes made since the last saving and ask the user to save the profile or confirm to discard the last changes made.

2.1.6. Annotations for Profiles

SchemaProf supports both global and local annotations.

Global annotations that refer to the application profile as a whole can be entered when the root element on the left side is selected. It is recommended to make annotations and provide descriptions and explanations to the users of the profile whenever possible. For more details please read section 4.1 Global Annotations.

Local annotations are attached to modifications (see section Modifications) and provide a possibility to explain and document the intention of this specific modification. This can become very useful when editing a profile (possibly created by someone else) and the idea behind a modification it is not obvious what might often be the case. The following sections on modification show how to make local annotations.

We recommend to use annotations extensively since it provides a way of inline documentation to provide information that can be extracted later on, e.g. when uploading a profile to the Application Profile Repository.

2.2. Modifications

To make, edit, delete or rearrange modification to your specification’s XML schema, you must first locate and select the element to be modified in the navigation tree on the left side of the program window. The right side of the windows then shows the list of all modification of the currently marked element, if any exist already.

On top of the right side you see the default settings of the element as given in the base schema. On the rightmost side of the program window you find buttons to create new modifications, edit or delete existing modifications, and to rearrange the modifications.

Figure 13: The Modifications Dialog

If modifications are applied to an element this element is highlighted in red colour in the navigation tree. The order of the modifications is important! If more than one modification is made, only the first valid modification is applied. See section Order of Modifications, Reordering Modifications for more information.

2.2.1. New, Edit, Delete Modifications

To enter a new modification select some element on the navigation tree on the left side and click the New button. This will open a wizard dialog specific to the current element type. For details on the possible values and meaning for specifying the modifications please refer to the following sections Cardinality Type Modifications and Value Type Modifications.

Elements denoted with a folder symbol () in the navigation tree can not be modified. Still Assertions and, if extension points are enable in the preferences, Modification Extensions are possible for those elements.

To edit a modification select the element in the navigation tree on the left side first. Modified elements are highlighted in the navigation tree. Then select the modification you want to edit in the working area on the right side. Now press the Edit button to edit the selected modification. For details on the possible values and meaning for specifying the modifications please refer to the following sections Cardinality Type Modifications and Value Type Modifications.

To delete a modification select the modified element in the navigation tree on the left side first, then select the modification you want to modify on the right side. Now press the Delete button with the modification selected and confirm the deletion.

2.2.2. Order of Modifications, Reordering of Modifications

For a single element, more than one modification can be specified. But only one modification will be applied for each element. Which modification will be applied is determined by the order in which the modifications are given and by the conditions given for the modifications. The first modification whose condition is evaluated to true will be applied. All modifications following this modification in the list of modification are ignored.

This means that the order in which the modifications are arranged in the list is important. Modifications that are not bound to a condition (unconditional) are treated as having a true condition. Any modification appearing after an unconditional modification will never be applied. To change the order of the modifications select a modification from the list and use the Move Up and Move Down buttons to move it up or down in the list.

2.2.3. Cardinality Type Modifications

Cardinality Modifications are possible for the cardinality elements that are denoted different icon symbols and the description [CardinatilityElement] in the navigation tree on the left side.

The icon symbols also indicate the cardinality of the unmodified element:

	Mandatory single element of this type
	Mandatory element that must occur at least once, but is limited to a maximum number of occurrences.
	Mandatory element that must occur once and may occur as many times as wanted (unbounded).
	Forbidden element that may not be used.
	Optional element that may or may not be used. If used, only a single occurrence is allowed.
	Optional element that may or may not be used. If used, only a limited number of occurrences are allowed.
	Element that must have a fixed number of occurrences (>1).
	Mandatory element that has a minimum and a maximum number of occurrences set.
	Mandatory element that must have a minimum number of occurrences, no maximum number of occurrences set (unbounded).

Table 3: Cardinality Symbols

Clicking the new button will open a dialog box that allows modifying the minOccurs and the maxOccurs values. Compatibility is preserved according to the current compatibility level. The drop-down boxes for the minimum and maximum number of occurrences show only the values allowed in the current compatibility level. See section Compatibility levels for further details on the available compatibility levels and associated restrictions.

Optionally an annotation and a condition may be entered. Annotations consist of a category, a language and the annotation text. Use the button New to enter your annotation. The condition is chosen with the drop-down list that shows all conditions specified for the profile by the user. If a condition is chosen, the modification will only be applied if the given condition evaluates to true.

Use the condition manager to view, edit or create conditions. To change a conditional modification back to an unconditional modification, select the top element ‘-none-‘ from the drop-down list of conditions.

Figure 14: The Cardinality Element Editor

2.2.4. Value Type Modifications

Value type modifications are possible for the value type elements denoted with the respective description [ValueTypeElement] in the navigation tree on the left side. Simple content elements (icon:) and attribute elements (icon:) are valid value type elements. Modifying a value type opens a wizard that offers four different replacements for the current value type and will take you step by step through all possible modifications.

Figure 15: Value Type Modifications

Figure 16: The new modification dialog for value types

Restriction of the selected type

This type of modification does not modify the base type itself, but makes it possible to enter several restrictions (facets) on the value space of current type. Further information on the restrictions, the syntax and validation is specified in the W3C document XML Schema Part 2: Datatypes (http://www.w3.org/TR/xmlschema-2/).

Step 1: Select the element you want to modify in the navigation tree on the left side. Then press the New button on the right side.

Step 2: Select ‘Restriction’ and press the Next > button.

Step 3: Enter the restrictions needed. Depending on the element type different facets (restrictions) are available. Leave all other fields untouched to not change the current values.

The tab length allows restricting the number of characters for a value. A fixed length, a minimum and a maximum length can be entered. More details on http://www.w3.org/TR/xmlschema-2/#rf-length.
The tab pattern allows entering of a pattern, constraining the lexical value space of a data type to literals which match the given pattern. The pattern is given as a regular expression according to http://www.w3.org/TR/xmlschema-2/#rf-pattern.
The tab enumeration makes it possible to define a set of values. The value space of the current element are then restricted to the values of this set only. See http://www.w3.org/TR/xmlschema-2/#rf-enumeration for more information.
The tab whitespace can be used to specify the handling of whitespaces in values of this element. Allowed values are preserve, replace and collapse. The meaning of the values is given in http://www.w3.org/TR/xmlschema-2/#rf-whiteSpace.

Figure 17: The Facets Modification Dialog

Press the Next button to continue, when all needed restrictions are entered.

Step 4: Enter a meaningful name for the new type that will be created based on the setting.

Step 5: In this step of the wizard, the following information can be entered:

One or more annotations may be entered for this modification. To enter a new annotation, use the New button on the right side. In the opening dialog the text can be entered. Each annotation is bound to a category and a language, which can be selected below. The category can be selected to be explanation or rationale. The language can basically be any language string as defined in http://www.w3.org/TR/xmlschema-2/#language (based on RFC 1766). The most common language strings are available in the drop-down-box, but it can also be overwritten. Corrections are possible using the Edit and Delete buttons.
A condition that must be satisfied, to activate this modification. Use the button Condition Manager to enter a new condition or modify an existing condition. The conditions are used to determine whether a modification is applied at all, and respectively which modification is applied when several modifications are given (see section ‘Order of Modifications, Reordering of Modifications’ above for more information and section Condition Manager for more details).
The usage declaration of attributes allows the values: optional, prohibited and required. See http://www.w3.org/TR/xmlschema-1/ for further explanations.
An initial value for this element can be used. If it is given as a default value, the user of this profile can overwrite this value entering an own value. If the value is given as fixed value, no changes are allowed by the user.

Click Next button to continue.

Figure 18: The modification attributes dialog for value type modification

Step 6: Enter Attribute Extensions, if needed, and click Next button.

Step 7: Finalize this entry by clicking the Finish button.

Replace by an existing type

Use this option to replace the predefined type with some other type. The value space of this element is then set to the value space allowed for the new type.

Step 1: Select the element you want to modify in the navigation tree on the left side. Then press the New button on the right side.

Step 2: Enter a meaningful name for this modification and press the Next button.

Step 3: Select ‘Replace Type’ and press the Next button.

Step 4: Select the new base type you want to use instead of the current base type from the drop-down list and press Next to continue.

Step 5: Enter or modify (if required) the settings for annotations, conditions, usage and default value. See Step 5 of the previous section for details. Press button Next when done.

Step 6: Enter Attribute Extensions, if needed, and click Next button. (This is only visible if extension points are enabled in the preferences.)

Step 7: Finalize this entry by clicking the Finish button.

Figure 19: The 'Replace Type’ Modification Dialog

Replace by a union of existing types

Use this option to replace the current type with a union of several base types. The value space of this element will then be changed to the union of all value spaces given in the list of types.

Step 1: Select the element you want to modify in the navigation tree on the left side. Then press the New button on the right side.

Step 2: Select ‘Union’ and press the Next button.

Step 3: Compile a set of type to be joint in a union. To add a type to the set of types, select the type from the drop-down list and press the Add button. The type will now appear on the list below. To remove a type from the list, select the type from the list and press the Delete button. Press Next when all required type are on the list.

Step 4: Enter further information (if required) as described above and press the Next button.

Step 5: Enter a meaningful name for the new union type and press the Next button.

Step 6: Enter annotations, conditions, usage information and a default value as explained above and press Next .

Step 7: Finalize this modification by clicking the Finish button.

Figure 20: The ‘Replace with Union’ Modification

Replace by a list of existing types

Use this option to define a data type that will be derived from an atomic or union data type. The value space of this element is then composed of a finite-length sequence of values of the specified type.

Step 1: Select the element you want to modify in the navigation tree on the left side. Then press the New button on the right side.

Step 2: Select ‘List’ and press the Next button.

Step 3: Select the base type of the list from the drop-down list. Press Next to continue.

Step 4: Enter further facet information as explained in Step 3 above. Then press the Next button.

Step 5: Enter a meaningful name for this modification and press the Next button.

Step 6: Enter annotations, conditions, usage information and default value as explained in Step 5 above, if required, and click Next button.

Step 7: Finalize this entry by clicking the Finish button.

Figure 21: The Replace with List Type Modification

2.2.5. Global and Local Modifications

Sometimes an element of a base XML schema (referring element) is defined using a reference to another schema element (referred element). More than one referring element can exist, pointing to the same referred element. If the referred element is modified, this of course has impact on all referring elements.

When a modification must be made to the referring element, a decision must be made whether to do a global and local modification.

Global Modification: When the referred element is modified, this is a global modification. This modification will affect any other schema element that has a reference to this element.

Local Modification: This modification is made to a referring element. It will modify only this schema element. It leaves the referred element untouched, thus having no influence on all other elements referring to the referred element.

SchemaProf is able to make local and global modifications for an application profile. If a schema element in the navigation tree is shown in grey coloured text, this means that this is a referring element. By default no modification can be made to this element. This forces the user to decide whether to make a global or a local modification at this point.

To make a global modification, the user must switch to the position in the navigation tree where the referred element is found. The easiest way to find the global definition is right-clicking the referring element and clicking ‘Focus Global Element’ from the context menu. Now you can modify this global definition. Making a modification to this referred element will affect all XSD elements referring to this element.

To make a local modification, the user must toggle the activation state of the referring element first. This is done by right-clicking on the referring element in the navigation tree and selecting ‘Activate’. This changes the text colour to black and allows from now on making (local!) modification to this XSD element. These modifications will be realized as local modification in the application profile, influencing only the current element and leaving the referred element and any other XSD elements untouched.

Figure 22: Deciding for a local or global modification of a referring element.

The internal realization of the local modification is done by defining a new XSD element type, making a copy of the referred element under a different name, and replace the reference of the with a type attribute pointing to the new XSD element type. All modifications made are applied to this new XSD element type only. This leaves the referred element and all elements referring to it untouched.

Note: A local modification is always based on a copy of the original specifications type that is referred (referred element). If this type definition of the referred element was modified in your profile before, this modification is not considered in any local modification of this type. The local modification is always based on a copy of the unchanged type definition as found in the original specification.

2.2.6. Extending a specification

Mild Extensions and Domain Profiling Extensions

Modifications on wildcard elements are possible where the wildcard elements any and anyAttribute signal a foreseen extension point in the XML schema. Selecting an any or anyAttribute element in the navigation tree on the left side shows the configuration of this element in the base specification on top of the right side of the window. Press the New button on the right side to modify this extension point.

Figure 23 Extension Point Modification

The modification dialog allows redefining the following setting for this extension point:

Process Content

This value specifies how the XML processor should handle validation against the elements specified by this any element. See Table 4 for the possible values and their meaning.

strict	The document processor must validate the given document element against the allowed namespaces and profiles. If the schemas and profiles are not available and no validation is possible, the validation will fail.
lax	The document processor will try to validate the element against the namespace or profile. If the schema or profile is not available, no validation error is reported.
skip	No validation of the element will be performed.

Table 4 Processing options for extension points ('any' elements)

Namespace / Application Profile List

This list contains the allowed namespaces and/or application profiles. The document instances will be restricted to contain only those elements from the defined namespace and profiles at the position of the current extension point. More than one namespace or profile may be defined; namespaces and profiles can be mixed. In the list of allowed namespaces and profile, the namespaces are identified by the icon and application profiles are identified by the icon.

Using other application profiles, while profiling a specification’s extension point, is one form of domain profiling. For more information on domain profiling please refer to the Telcert website [1] or the IMS Abstract Framework Glossary [2].

Use the first dropdown list to select whether you want to add a namespace or an application profile to the list. The second dropdown list offers the options which differ for regular namespaces and application profiles. See Table 4 and Table for the list of available values and their meaning.

Use the Add button to add the currently selected chose of a namespace or profile to the list. Use the Profile Manager button to start the profile manager for the management of profiles used and possibility to quickly switch editing to the other profile.

Browse…	Selecting this line will open a file dialog to choose an application profile XML file from the local file system.
Choose profile from list	Any application profile used before in this profile will be offered to the user in the dropdown list for easy re-use.

Table 3: Possible values for profiles

##any	“Any well-formed XML from any namespace (default).”[3] This namespace makes no restrictions at all, therefore no other namespaces or profiles are allowed in SchemaProf when ##any is on the list.
##local	„Any well-formed XML that is not qualified, i.e. not declared to be in a namespace. “³
##other	“Any well-formed XML that is from a namespace other than the target namespace of the type being defined (unqualified elements are not allowed).”³Like ##any, including this namespace in the list will prevent adding any other namespace or profile.
##targetNamespace	“Any well-formed XML belonging to any namespace in the (whitespace separated) list; ##targetNamespace is shorthand for the target namespace of the type being defined“³
Choose namespace from list	Any namespace used before in the current profile and thus known will be display in the list for re-use at another location and can be selected.
Typing another namespace	To be able to add any further namespace, the user can type any namespace into the dropdown filed and add it to the list.

Table 4: Possible values for namespaces

Cardinality (only type any elements): The cardinality of this element can be modified by entering new values for the minOccurs and maxOccurs values.

Condition: A condition can be chosen from the dropdown list. This condition must be satisfied to activate this modification. Use the button Condition Manager to enter a new condition or modify an existing condition. The conditions are used to determine whether a modification is applied at all, and respectively which modification is applied when several modifications are given (see section ‘Order of Modifications, Reordering of Modifications’ above for more information).

Figure 24 Extension point modification window

Modification Annotations: One or more annotations may be entered for this modification. To enter a new annotation, use the New button on the right side. In the opening windows the text can be entered. Each annotation is bound to a category and a language, which can be selected below. The category can be selected to be explanation or rationale. The language can basically be any language string as defined in http://www.w3.org/TR/xmlschema-2/#language (based on RFC 1766). The most common language strings are available in the drop-down-box, but can be overwritten. Corrections are possible using the Edit and Delete buttons.

Click the OK button when all information is entered. The modification can be edited later on using the Edit button or removed using the Delete button and rearranged using the Move Up and Move Down buttons.

Wild Extensions

An XML schema should only be extended at pre-defined extension points that are foreseen by the schema developer and identified in the schema by the names any and anyAttribute. Those ‘legal’ extensions are denoted as mild extensions and their usage is described in the previous section.

Unfortunately there are rare situations where extensions to a schema are necessary and no extension points have been foreseen by the schema designers. For these cases it is possible to extend the schema at other positions, making a so-called wild extension.

We strongly discourage the usage of wild extensions.

Using wild extensions will destroy any compatibility to the base specification and software that is not fault-tolerant might behave unexpectedly or even crash when wild extensions are used.

If the usage of wild extension can not be avoided select the element that is considered the predecessor element of the extension element in the navigation tree. Press the New button on the right side to enter an extension at this point. This will pop up a window for text input where you can enter the new element in pure XML code.

Entries made for wild extensions are not checked at all except for being well-formed. Since wild extensions are beyond any specification or standard only very experienced users are expected to use this feature and no further support is provided.

2.2.7. Profiling Extensions

The XML file format of the application profile is also specified by an XML schema. The previous section mentions that in rare situations extensions are necessary but have not been foreseen by the schema designer.

To allow future extension to the schema profiling as used and supported by SchemaProf, the profiling schema has some extension point that are not used by the SchemaProf profiling tool itself. They are intended to be used for community specific extensions.

SchemaProf, although not able to semantically ‘understand’ the meaning of the profiling extensions allows the user to enter them at the pre-defined extension point. This can be done by selecting the root element in the navigation tree on the left side. The working area on the right side now show five tabs apart from the ‘Global Schema Annotations’ tab. Select a tab and enter your extensions by pressing the New button and entering the XML code as described in the previous section.

2.3. Additional Constraints

The intention while developing the TELCERT tools was not only to support localization of existing specifications for community needs, but also to accomplish a maximum of interoperability with the original specifications. During the work we had to realize the XML schema language itself is not powerful enough to express some of the constraints defined in specification.

The TELCERT tools therefore go beyond XML schema profiling and allow you to define further aspects of specifications. The conditional modifications, covered in the previous sections, are one example of definitions that are beyond the scope of the XML schema language. Now we introduce another capability, the definition of additional constraints in a generic form.

With additional constraints is possible to define extra information that is used in other tools to check constraint that are often found in the information model of specifications but is not found (in machine readable form) in the XML binding. If for example an attribute ‘fileURI’ is supposed to point to an existing file that must be an HTML file and of the size defined in the further attribute ‘fileSize’, that is not possible with the XML schema language only.

The concept of additional constraints makes it possible to define exactly such constraints. The main advantage of defining constraint in a machine readable form is the automated verification of the constraint through appropriate tools like the TELCERT test system.

Currently two types of constraints are identified and supported. File constraints define the location of a file and several properties this file must comply to like file extensions, file size or file type. Vocabulary constraints make it possible to tie certain element values to a vocabulary (internal or external) where this value must be contained.

In application profiles the additional constraint are defined formally. Verification can only take place for document instances filled with values that are expected to comply with this application profile. The more constraints are defined formally in the profile, the more exactly the test system can ensure the correctness of any document instances and therefore ensure a higher chance for compliance to the base specification.

Adding a new constraint

To define new constraints please click on the ‘Constraints’ tab above the navigation tree in the upper tabs row. The seconds row of tabs is only visible when the ‘Categories’ tab is activated and will disappear when switching from the default view. Now a different navigation tree is displayed and below two buttons are shown to add or delete new constraint.

Figure 25 Adding and Deleting Constraints in SchemaProf

Click the button New constraint… to start a new constraint. In the dialog opening now, choose whether to add a file constraint or a vocabulary constraint and give the constraint a name. Then click Next > to continue. For file constraints a file URI must be defined immediately since this is a mandatory definition that may be modified but never deleted. Then click Finish to get back to the main window where further constraint definitions can be inserted.

Deleting a Constraint

To delete an additional constrain select the constraint in the navigation tree and then click the Delete Constraint button below the navigation tree. If the ‘Categories’ tab is currently selected it is necessary to click on the ‘Constraints’ tab before to get the correct view of the navigation tree.

Constraint Definitions

Each constraint defined in a profile consists of one or several definitions. Each definition specifies a specific property that any document instance must satisfy, e.g. a certain file type or file size. A document instance can only be considered a valid document if all constraint definitions are satisfied, e.g. the file type must be HTML and the size must be less then 1 MB. Within the definitions alternative value may be possible, e.g. the file type restricted to DOC or PDF. Each definition can occur only once within the same constraint, e.g. it makes no sense to have two declarations of a maximum file size.

Adding a Constraint Definition

To add a constraint definition, first select the constraint in the navigation tree on the left side. The constraint must exist already; see section Adding a new constraint on how to create a constraint. On the right side you can see the existing definitions of that constraint if any exist.

No click the New definition button on the right side to add a new definition to the list. Depending on the constraint type (file constraint, vocabulary constraint) different definitions will be available. It is possible that some definitions are disable if they are is use already or conflict with definitions in use.

Figure 26 Adding, Editing and Deleting a new constraint definition

Deleting or Editing a Constraint Definition

To delete a constraint definition, select the constraint first in the navigation tree on the left side. Now you see the list of existing definitions in the list on the right side. Select the constraint definition you want to delete from the list and click the Delete Definition or Edit Definition button.

2.3.1. File Constraints

File constraints define the location of a file and several expected properties of that file. All values can be defined by pointing either to a schema element (value type or attribute) or by setting a user defined value. Each setting made is called a constraint definition. Several constraint definitions can be combined, but not all combinations are allowed. SchemaProf will only offer you those constraints that are allowed at the current stage.

Figure 27 The Definitions of a File Constraint

FileURI Definition

The FileURI definition declares the actual file location. This can be done directly with a user-defined URI value, or indirectly by choosing a schema element that will later hold the file location. The indirect definition is probably the more commonly used option since it is used in several specifications like IMS Content Packaging. The direct definition on the other hand is more intuitively used for profiling and less abstract to understand. The FileURI is mandatory.

FileExtention Definition

With the FileExtention definition it is possible to define a list of file extensions, e.g. “html, htm, php”. The file extensions are of course alternatives and each filename in a document instance must end on one of the file extensions. Example: “http://mydomain.org/index.html” is a valid filename, while “myScript.pl” is no allowed.

FileSize Definition

This definition specifies the absolute size of a file. This definition typically points to an attribute where a system is expected to continuously update the exact file size as meta data. Setting a user-defined value in the profile is probably unrealistic but still allowed.

Additionally a divisor must be set, defining whether the given size is expected to be byte (divisor: 1), kilobyte (1024) or megabyte (1024x1024). A user-defined divisor is also possible.

The FileSize definition cannot be used in combination with the FileMinSize and FileMaxSize definitions. If FileSize is defined FileMinSize and FileMaxSize are not available and vice versa.

FileMinSize, FileMaxSize

These definitions allow you to set a minimum or maximum file size. The size can be given, as for fileSize, in byte, KB, MB or any user-defined divisor. Setting one or both of these definitions prevents the use of the FileSize definition (absolute size).

FileDirectory

This definition defines a directory where the file is expected. This can be a document attribute within the document instance or a user-defined and therefore fixed value. If defined, the file must exist in this directory.

FileMimetype

With this definition a list of MIME types can be specified, e.g. ‘application/pdf’ or ‘text/xml’. If more than one MIME type is given, they are considered to be alternatives. If defined, the file of this constraint is expected to comply with one of the given MIME types.

FileValidation

The FileValidation setting allows you to specify a XML schema or a DTD file. The actual file in the document instance in then expected to be compliant to this XML schema or DTD and it’s the task of the test system or other tools to verify the compliance.

2.3.2. Vocabulary Constraints

Vocabulary constraints define a schema element and a vocabulary. The value of the schema element in a document instance must then be contained in the given vocabulary. Only these two constrain definitions are available.

VocabularyElement

This definition specifies the actual schema element that will later hold the actual value. Here a user-defined value makes no sense and is not allowed. The schema element can be an attribute or a value type element.

VocabularySource

The definition specifies the actual vocabulary. The vocabulary must be of the format IMS VDEX or XVD. The location where the vocabulary can be found is defined through a schema element or a user-defined value. Additionally the vocabulary type must be set.

2.4. Annotations

SchemaProf allows the user to make annotations at different levels and positions of the profile. The extensive usage of the annotation feature is recommended to improve the understanding and correct usage of the profile by users that are not involved in to profiling process. The annotations can always be made in one or more languages supporting multilingual applications.

The following subsections describe the available positions for your annotations.

2.4.1. Global Annotations

Global annotations are available to enter annotations that concern the application profile as a whole. To make a global annotation, select the root element of the base specification in the navigation tree. The working area on the right side will show several tabs on top; please select the tab Global schema Annotations and click on the New button.

Figure 28: Global Annotations

Now one or several annotations can be entered by clicking on the New button and entering the information. An annotation consists of the annotation text bound to a category and a language.

The categories available for the global annotations are name, scope, policy, conformance and general.

The language can basically be any language string as defined in http://www.w3.org/TR/xmlschema-2/#language (based on RFC 1766). The most common language strings are available in the drop-down-box, but can be overwritten.

Figure 29: Inserting a New Annotation

Annotations can be edited and deleted by marking them in the list and clicking the Edit or Delete button.

2.4.2. Modification Annotations

For all types of modifications, it is possible to make annotations. Annotations for modification can be categorised to be either ‘explanation’ or ‘rationale’, and the language of the annotation can be specified by selecting one of the languages from the dropdown list or write your own language in this box. For every combination of category and language string only one annotation is allowed.

2.5. Managers

2.5.1. Type Manager

The type manager is the user interface to manage user defined types for your currently opened application profile. You can enter a new type and edit or delete existing types. The type manager is started by the menu entry Manager ► Type Manager.

Figure 30: The Type Manager

New Type

To add a new type to your application profile, press the New button. This opens a dialog window offering three basic possibilities to derive a new type: make a restriction to an existing type, create a union of several existing types, or create a list of existing types. They are explained in detail in the following.

Create new type from a restriction of an existing type

Step 1: Enter a name for the new type you are creating now.

Step 2: Select Restriction.

Step 3: To define a new type based on a restriction of an existing type, you must now choose the base type from the drop-down box below. Then press the Next button.

Step 4: Enter the restrictions to be made to the basic type. Leave all other fields untouched to not overwrite the current values. The restrictions available depend on the base type you have chosen in the previous step. The following restrictions are possible:

The tab length allows restricting the number of characters for a value. A fixed length, a minimum and a maximum length can be entered. More details on http://www.w3.org/TR/xmlschema-2/#rf-length.
The tab pattern allows entering of a pattern, constraining the lexical value space of a data type to literals which match the given pattern. The pattern is given as a regular expression according to http://www.w3.org/TR/xmlschema-2/#rf-pattern.
The tab enumeration makes it possible to enter a set of values. The values of this element are then restricted to this set of values. See http://www.w3.org/TR/xmlschema-2/#rf-enumeration for more information.
The tab whitespace can be used to specify the handling of whitespaces in values of this element. Allowed values are preserve, replace and collapse. The meaning of the values is given in http://www.w3.org/TR/xmlschema-2/#rf-whiteSpace.

Press the Next button to continue, when all restrictions are entered.

Step 5: Press the Next button to finish this type.

Create a new type from a union of existing types

Step 1: Enter a name for the new type you are creating now and press Next to continue.

Step 2: Select Union and press Next to continue.

Step 3: To add a type to the list of types to unify, select the type from the drop-down list and press the Add button. The type will now appear on the list below. To remove a type from the list, select the type from the list and press the Delete button. Press Next when all required types are on the list.

Step 3: Press the OK button to finish this type.

Create a new type from a list of existing types

Step 1: Enter a name for the new type you are creating now and press Next to continue.

Step 2: Select List and press Next to continue.

Step 3: Select the type from the drop-down list, the new list element should be based on. Press Next >> to continue.

Step 4: Press the OK button to finish this type.

Edit Type

To edit a previously user defined type select the type from the list of available types. Then press the Edit button. Depending on the nature of the type (atomic, union or list) a different dialog window will open.

The information you can enter in the fields of this dialog are a combination of the fields offered in step 2 and step 3 of the New Type operation above. Please refer to the description above for further explanations.

Delete Type

To delete a previously user defined type select the type from the list of available types. Then press the Delete button. This will delete the currently selected type.

To close the Type Manager use the Close button or the X symbol.

2.5.2. Condition Manager

The Condition Manager is the user interface to manage the conditions defined by the user. The window shows a list of all defined conditions. A condition has an ID, a name and the condition declaration.

The ID is set by the system and must be unique. It is used to identify the condition internally; the user may not change this ID himself.

The name is given by the user and should be a meaningful name to identify the condition. The name is presented to the user whenever he has to select a condition.

The condition declaration can be any valid XPath expression that is evaluated to the Boolean values. See below for further explanations on declaration of conditions.

Figure 31: The Condition Manager

Declaring XPath Conditions

A condition for SchemaProf is generally any valid XPath expression that is evaluated to the Boolean values of either true or false. See http://www.w3.org/TR/xpath#booleans for further information on Boolean objects and their evaluation according to the W3C recommendations. Expressions evaluating to any other value, e.g. to 1 or 0, are not allowed!

You may e.g. use functions, refer to schema elements and their values, or use Boolean and comparison operators. For an authoritative and up-to-date explanation on XPath expressions always refer to the W3C recommendations given above. For a simple and quick overview on the XPath expression elements you can also use some quick reference available on the internet, e.g. http://gordon.inf.ethz.ch/lectures/isk2003/XPath.pdf.

Whitespaces can be used for better readability and are preserved. They should not influence the evaluation of the condition, but this depends on the program working with your profile. According to W3C recommendations, all of the following expressions should be evaluated to the same value:

( @myAttribute <= ( count( ../someStructure ) ) )

(@myAttribute <= ( count(../someStructure)) )

( @myAttribute<=(count(../someStructure)))

(@myAttribute<=(count(../someStructure)))

Examples of Conditions

true()
This is a valid condition, making use of the Boolean function true() that will always evaluate to the Boolean value true. The condition will therefore always be satisfied.
true
This is also a valid condition, but does not refer to the Boolean value true, but to an element with name “true” in the current element structure.
@myAttribute = “myValue”
This condition will evaluate to true, if the value of the attribute “myAttribute” of the current element is set to “myValue”. Otherwise it will evaluate to false.
( (name(..) = “item”) or (name(../..) = “item” )
This condition evaluates to true if the name (function “name()”) parent element (“..”) or the grandparent element (“../..”) of the current element is “item”. Otherwise it evaluates to false.
Assuming that the current element is also called “item”, this condition can be used to detect it some elements are iterated in the profile structure, that is the element “item” contains other elements called “item”.
count(../someListElement) <= “5”
This condition evaluates to true, if the list element “someListElement, located one level above the current element in the element hierarchy of the profile, consists of no more than 5 list element. Otherwise it evaluates to false.

2.5.3. Namespace Manager

The namespace manager gives you an overview of the namespaces used in your profile and the namespace prefixes they are mapped to.

Additionally it let’s you control the target namespace of your profile. Profiling a specification does make changes to the original and therefore the original namespace should not be used, although the compatibility to the original specification is preserved especially in the restrictive mode of SchemaProf. By default the STT tool will change the target namespace by appending “_localized” to the original namespace string. In the namespace manager you may also control the target namespace by setting a user-defined namespace which will then be used by STT.

Figure 32 The Namespace Manager

2.5.4. Profile Manager

The profile manager provides the user a complete list of all the profiles that are used at the extension points of the current profile. If the same profile is referenced at more than one extension point of the current profile, it will still appear only once in the profile manager.

Please note than that the profile manager will only show those profiles that are referenced directly from the current profile. If a referenced profile again references further profiles (therefore indirectly referenced by the current profile), they are not shown in the list.

Figure 33 The Profile Manager

Despite giving an overview over the referenced profiles, the profile manager profiles the following functionality:

Open Profile

A profile referenced by the current profile can be opened for editing using the profile manager. Select the profile to open from the profile manager list and press the Open button. This supports the concept of domain profiling where several specifications are used in combination, and therefore should be profiled together.

Prior to closing the current profile, SchemaProf will ask the user to save the current profile if any changes have been made that are unsaved.

To come back to the previous profile, please use the functionality of the file history.

Replace Profile

It is possible to modify all references of a profile to reference another profile. This functionality is provided to allow easy replacement of a profile by a new version of the profile. This will hopefully improve consistency of a profile when a profile is referenced more than once. Even if the profile is referenced only once, access to it is much easier through the profile manager instead of having to locate the extension point in the depth of the navigation tree first.

To replace all occurrences of a profile, select the profile from the profile manager list and press the Replace button. This will open a file selection dialog, where you choose the new profile XML file to be used. After pressing ‘Open’ all occurrences are replaced.

2.5.5. Constraints Manager

As explained in previous sections, the profiles defined with SchemaProf are capable of expressing more than the XML schema language, among others by defining additional constraints. To be able to use these advantages for the base specifications themselves already, not only for the profiled specifications, SchemaProf provides the possibility to write a additional constraints file that is used and profiled with the base specifications XML schema. Chapter Additional Constraint Authoring explains in detail how to create an additional constraints file.

When creating a new profile it is possible to specify one or more additional constraints files to be used. These setting can be accessed through the constraints manager after the creation of the profile. Here further additional constraints file can be specified and existing file can be removed.

Figure 34 The Constraints Manager

2.5.6. Profile Repository Manager

The Knowledge Media Institute at the University of Koblenz offers the network resources for an application profile repository at http://iwm.uni-koblenz.de/profiles/. The intention of this repository is to foster the community exchange of profiles. The repository contains a set of publicly available profile as examples of profiling and allows you to search for profiles based on the same base specifications or provided by a specific author. Chapter Application Profile Repository explains in detail the possibilities and use of the repository.

SchemaProf has support for the profile repository integrated. Once you have created your profile it is possible to upload your profile directly to the repository using the profile repository manager. This is realized through a web service that is communicating with the repository.

Settings

The tab Settings from the Profile Repository Manager must be set to the URL of the web service that is in charge of ingesting the profile to the repository. SchemaProf will have the current URL set as default in its releases, so this setting must probably never be changed. If the upload does not work correctly please check with the current URL published on the Profile Repository website.

Login

On the Login tab the user setting for the access to the repository can be made. The username and password must be requested via email, see the Profile Repository website for details or click on the link at the bottom of the dialog window.

The default repository URL should probably work for everyone. To be flexible and support possible other repositories in future it is possible to change the URL anyway.

Figure 35 Profile Repository Manager

Upload

The Upload tab finally allows you to enter metadata about the profile. When a search on the repository for a profile is made, this metadata is the relevant part that is searched.

Here you are able to enter the values for

§ Profile Author: your full name (not the login name).

§ Profile Name: a meaningful name for the profile (not the file name).

§ Keywords: any other keywords like “Content Packaging”, “WebCT” or “Uni Koblenz”.

SchemaProf will extract additional information from your profile automatically and make it available as metadata. The additional information is:

§ The base schema namespace (e.g. “http://www.imsglobal.org/xsd/imscp_v1p1”).

§ The date of your upload.

§ The annotations you entered as global profile annotations.

Profiles will be uploaded to the repository as zipped profile and can be downloaded from the repository in the same format to be opened with SchemaProf for viewing or editing. Profiles downloaded from the repository are recognized by SchemaProf so that a second or later upload will be realized as an update if uploaded from the same person (login name).

Press the Upload button to finally upload your profile.

2.6. Assertions

SchemaProf allows the definition of assertions in profiles that can be used as a further instrument to ensure compliance and consistency of document instances with profile and specifications respectively.

Assertions are specified in form of XPath expressions that are evaluated to either true or false. The possibilities what kind of conditions can be expressed are the same as for the conditions from conditional modifications.

But the logic behind them is different. Assertions are not tied to a schema modification. The XPath expression of an assertion must be evaluated by a tool (e.g. the TELCERT test system) for a specific document instance. If it evaluates to true this consistency check is satisfied what should hopefully happen for all your document instances. But if it evaluates to false, then this consistency check failed and the whole document instance is considered to be invalid! (For conditional modifications the XPath expression triggers a modification when evaluated to true and nothing happens if it evaluates to false.)

Creating a new Assertion

Assertions can be defined for most of the elements shown in the navigation tree. Make sure that the Categories tab is selected on the left side and select the element from the navigation tree where you want to attach the assertion to. Now a second tab, labelled Assertion, should be visible on top of the right side. Click it to get the assertions view.

To create a new assertion, now click the New button on the right side. A new dialog will open now with a text field where you can enter the XPath expression to be evaluated. Please refer to the section Declaring XPath Conditions for help on how to specify XPath expression. Click Next to continue.

On the next panel it is possible to make annotations and even to use a condition thus making it a conditional assertion. Click Next to continue and Finish to finalize this assertion.

Editing an Assertion

To edit an existing assertion select it from the list of assertions and click Edit, or double-click the assertion in the list.

Figure 36 Adding a new Assertion

Deleting an Assertion

Select the assertion from the list, click Delete and confirm the deletion.

Moving Assertions Up/Down

If more than one assertion is defined, it is possible to rearrange the assertions. This may be important for conditional assertions. Select an assertion and press the Move Up and Move Down buttons to rearrange.

2.7. Profile Extension Points

Most specifications include extension points at several positions of the XML schema for specific and unforeseen information that must be include in a document apart from the foreseen basic data structure. The application profiling XML format is also defined as an open format with several extension points. This preserves the flexibility to inserting data into profiles that was not foreseen while developing the application profiling specification or is specific to your local requirements and/or may be supported by your own tools.

Since this is a very advanced idea than will probably be used by very few people and may confuse less experienced users, the control extension of the extension points must be enabled in the preferences. Open the preferences and enable the checkbox Extension Points under the Global Setting tab to make the extension points visible in the GUI.

Figure 37 Enabling of Profile Extension Point.

Once enable the extension points are visible for these elements:

§ Root element of the profile: the new tabs Annotation Extension, Definition Extension, Mapping Extension, Modification Extension and Section Extension are now available on top of the right side.

Figure 38 Extension points of the root element.

§ For each of the complex types a Modification Extension tab is now available.

To enter your own XML data at these positions please enter the appropriate XML code into the text boxes and don’t forget to declare any namespaces and prefixes to be used in the namespace manager.

3. Additional Constraint Authoring

The XML schema language that is used by many specifications to realize a concrete binding of the data structures used can express most constraints of the data structures used. Some few constraints unfortunately can not be expressed in the XML schema language, but are defined in the textual descriptions of the specifications.

The TELCERT project, dedicated to testing against (profiled) specifications has defined a machine readable XML format of additional constraints that can capture some more type of constraint to make them available for tool support and for testing. This concept foresees two possibilities where additional constraint may be used.

A primary additional constraint file can be created for a specification. This process is based only on the base specification’s XML schema and is called additional constraint authoring. This process of creating and maintaining the primary additional constraint file is supported by SchemaProf v4 and is covered in this section.

Once a primary additional constraint file has been created, it can be used in combination with the base XML schema for further activities like schema profiling, content creation and content testing. The profiling of a specification that comes with an additional constraints file is covered in the section Schema Profiling above.

Figure 39 shows this concept in a diagram, i.e. how the additional constraints are integrated into the profiling process.

Figure 39: Constraint authoring and specification profiling

Different categories of additional constraint have been identified so far. Each category that is supported yet in SchemaProf is covered in a subsection below.

Basically, each constraint is identified by a unique constraint identifier and tied to a specific constraint category. Each constraint is made up of one or more constraint definitions. Each constraint category has specific definitions, that can be mandatory or optional or might occur once or many times.

Most constraints are related to the handling of files that are reference in the document instances of a specification. Those constraints are called file constraints and the first ones to be supported. The next type of constraints that are identified but not yet supported are VDEX constraints that refer to the usage of the IMS Vocabulary Exchange Definition Specification. Further constraints are likely to be identified later on and will be supported if demanded and as developer resources are allocated.

3.1. Additional Constraint File Handling

3.1.1. Creating a new Additional Constraints File

To create a new additional constraints file choose New… from the file menu or use the new icon () from the file menu. Then select to create a constraint file and choose the XML schema file for which to define the additional constraints. Then click Finish.

3.1.2. Opening an Additional Constraints File

The open existing AC files choose Open… from the file menu or use the icon from the toolbar. Then choose the file to open from the file explorer and click open.

To open a file that has recently been edited, you can also use the list of recent files in the file menu that stores the last 5 files that were edited with SchemaProf.

3.1.3. Saving an Additional Constraints File

To save the AC file you are editing use the Save or Save As… options from the file menu or use the corresponding icons and from the toolbar.

3.2. File Constraints

File constraint formalize requirements on file that are referenced in document instances and that must be satisfied by valid documents. Typically a specification may define that certain files must be found at predefined positions or at positions denoted by the values of attributes or elements of the document. Those files can further on be constraint by their file size, location, file type or content. All these constraints are specified in the definitions of a file constraint.

3.2.1. Creating a new File Constraint

To create a new file constraints select the constraints entry in the navigation tree and click the new button below the navigation tree. This will open a dialog where the user may choose the constraint category and the identifier of the new constraint (see Figure 40).

Figure 40: Creating a new file constraint

3.2.2. FileURI Definition

The FileURI definition specifies the file that is constraint in this constraint. Exactly one fileURI definition is required per file constraint, so it is a mandatory definition and usually the first one required. The actual file can be specified either by a fixed value given at the time of writing the file constraint, or it can be bound to a attribute of the XML schema when the actual file name and/or location is expected to be given in the document instance.

If fileURI is specifically specified by the constraint author this makes it a fixed value that remains unchanged for any possible document instances.

If the constraint author decides to have the file specified in an attribute of the document instances it is important that this value is really filled in any document instance.

A root location is must be defined first which will be the basis for any further definitions. All other definitions that refer to schema attributes are considered relative paths to this root location.

3.2.3. FileExtension Definition

The FileExtension definition specifies a file extension that the filename is allowed to have, e.g. “xml” or “jpg”. More than one FileExtension definition is allowed to be specified for a file constraint, then considering the given file extensions as alternatives.

The file extensions can be specifically defined by the constraint author, or certain schema attributes can be chosen that are expected to contain the possible extension in the document instances.

3.2.4. FileSize, FileMaxSize, FileMinSize Definitions

The definitions fileSize, FileMaxSize and FileMinSize restrict the given file in their size. All values can be given with a divisor (integer value or ‘MB’, ‘KB’) for easier definition of large file sizes or for document instances that contain the document size restrictions in values like megabyte or kilobyte.

The fileSize definition is intended to be used with a document instance attribute of a metadata structure that contains the exact file size. User defined value are usually not reasonable for this definition. If the fileSize definition is used, the FileMaxSize and FileMinSize must not be used since the exact file size unavoidably defines both the maximum and minimum size.

The FileMaxSize and FileMinSize definitions specify the upper und lower boundary of the allowed file size. Each of these two definitions is optional but may occur only once. The two FileMaxSize and FileMinSize definition may of course be used in combination. They must not be used in combination with the fileSize definition.

3.2.5. FileDirectory Definition

The FileDirectory definition allows specifying the allowed path where a file can be located. This is used when the fileURI definition does not contain the absolute or relative path to the file.

3.2.6. FileMimetype Definition

The FileMimetype definition specifies the allowed MIME type for file.

The MIME type can be specified by the constraint author and is then fixed for any document instances, or it may be defined indirectly through an attribute in the XML schema, whose value is then expected to contain the MIME type.

The FileMimetype definition is optional and may occur more than once. If more than one FileMimetype definitions are found they are considered to be alternatives, meaning than the file this file constraint refers to must be of any one of the defined MIME types.

3.3. VDEX Constraint

The VDEX constraints refer to the usage of the IMS Vocabulary Definition Exchange specification.

4. Plugins

4.1. Howto Plug-in

The Howto plug-in is the first plug-in written for SchemaProf and serve for demonstration purposes only. All it will do is to display a text description about how to write a plug-in.

4.2. Pretty Printing Plug-in

A simply pretty printing function that is useful to document the changes made to the base schema in a table.

4.3. Schema Transform Tool (STT) Plug-in

This plug-in is provided within the Telcert project by Apple and will merge the changes made to the base schema into a new XML schema and further files. For more information please refer to the SchemaProf website.

5. Application Profile Repository

The University of Koblenz has set up a simple repository service to foster the exchange of profiles between communities. The repository is available free and without charge, only a simple registration via email is required to prevent abuse. Please take a look at the Profile Repository Website for the most recent information:

http://iwm.uni-koblenz.de/profiles/

The repository is filled with many of the profiles that have been developed in the TELCERT project. Further profiles that are developed by the University of Koblenz, the TELCERT partners and others will be uploaded subsequently as they are developed.

Searching for Profiles

A Java Search Client has been developed that should be used to search for profiles relevant for you. Typical search criteria like “what profiles based on IMS LIP 1.0.1 are available” or “which profiles have been uploaded by a partner of me” can easily be defined with the search client.

Profiles that have been uploaded and declared to be public can be downloaded as ZIPed profiles and opened directly with SchemaProf. The profiles can be viewed as practice examples or edited to meet your own requirements.

Uploading of Profiles

New or modified profiles can be uploaded to the repository with SchemaProf’s built-in Profile Repository Manager. New profiles are created automatically and augmented with the metadata provided by the user before uploading (author name, profile name, keywords for search) and with metadata extracted automatically from the profile (base schema, further schema files, global annotations).

If a profile is downloaded from the repository, modified and again uploaded by the original author, it will be treated as an update of the original profile, not as a new profile. Nevertheless the original profile is not overwritten, a revision control makes it possible to restore older versions as well.

6. Known Issues

SchemaProf is under continuous development, making it even better for you. ;-)

Please refer our Bugzilla system for the current list of open issues at

http://iwm.uni-koblenz.de/bugzilla/query.cgi?product=TelcertSchemaProf

Please report any bug you find at the above Bugzilla system to support our development.

7. References

TELCERT Project Website: http://www.opengroup.org/telcert
Application Profile Repository: http://iwm.uni-koblenz.de/profiles/
“XML Schema Part 1: Structures”. W3C Recommendation, 2 May 2001, http://www.w3.org/TR/xmlschema-1/.
“XML Schema Part 2: Datatypes”. W3C Recommendation, 2 May 2001, http://www.w3.org/TR/xmlschema-2/.
“XML Path Language (XPath) Version 1.0”. W3C Recommendation, 16 November 1999, http://www.w3.org/TR/xpath.
“IMS Application Profile Guidelines Document, Part 1 – Overview”.
Version 1.0, 10 Oct 2005, http://www.imsglobal.org/ap/apv1p0/imsap_oviewv1p0.html.
“IMS Application Profile Guidelines Document, Part 2 – Technical Manual”.
Version 1.0, 10 Oct 2005, http://www.imsglobal.org/ap/apv1p0/imsap_techv1p0.html.

Appendix A – License

TELCERT SchemaProf – Application Profiling Tool

Copyright (c) 2004 Universität Koblenz-Landau, Institut für Wissensmedien.

Permission is hereby granted, free of charge, to any person obtaining

a copy of this software and associated documentation files (the

"Software"), to deal in the Software without restriction, including

without limitation the rights to use, copy, modify, merge, publish,

distribute, sublicense, and/or sell copies of the Software, and to

permit persons to whom the Software is furnished to do so, subject to

the following conditions:

The above copyright notice and this permission notice shall be included

in all copies or substantial portions of the software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY

CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,

TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE

SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Contact:

Ingo Dahn (dahn@uni-koblenz.de)

Institut für Wissensmedien

Universität Koblenz-Landau, Abt. Koblenz

http://www.uni-koblenz.de/iwm

Information on TELCERT Project:

http://www.opengroup.org/telcert/

This product includes software developed by the Eclipse Foundation http://www.eclipse.org.

This product includes software developed by the Apache Software Foundation http://www.apache.org.

Appendix B – Schema Transform Tool Plug-in Guide

This guide is kindly provided by Will Luxton from Apple Computer UK, the author of the Schema Tranform Tool (STT).

Introduction

This document is the operations guide for the use of the STTPlugin with the SchemaProf application. It is used to apply the Domain or Application Profile generated by SchemaProf against one or more base schema, producing a number of generated files that include the resultant schema, definitions files and constraints files.

Further information on the design of the underlying STT engine is listed in the design document.[4]

Usage

l Once an Application Profile (AP) has been created through SchemaProf, select the Plugins menu from the menu bar in SchemaProf.

l Select the Schema Transformation Tool menu item. If a valid AP has been is to be processed, select the Transform current Schema Profile menu item.

l In the plugin window click on the browse button (the button with the ellipsis) and navigate to a directory within your file system that is to act as the output directory for the generated STT files.

l Configure the additional options as appropriate:

l Add annotations to derived schema: If this checkbox is checked, any annotation elements defined in the AP will be transcribed to the appropriate position within the resultant schema, allowing comments of the changes to be retained.

l Create additional document for conditions: If this checkbox is checked, a separate file containing only the extracted conditions will be generated. This document can then be used as a basis for the application of conditions to other AP’s.

l Overwrite output files: If this checkbox is checked, existing files in the output directory with the same name will be overwritten by the produced resultant files of the STTPlugin processing. If the checkbox is not checked, and files with the same name as the files to be generated exist in the output directory, a warning will be generated and processing will stop.

l When the configuration is complete, click on the OK button to start processing or the Cancel button to result to the SchemaProf application.

l Once processing has been completed, any warning or information messages generated during the processing of the domain or application profile will be displayed.

Ó Apple Computer UK Ltd. 2005