APS Application Certification Criteria

1.2


Table of Contents

1. Introduction
2. Overview
2.1. Procedure
2.2. Result
2.3. Requirement changes
2.4. Application changes
3. Silver certification level
3.1. Package consistency
3.2. Application and vendor information
3.2.1. Application homepage
3.2.2. Packager information
3.2.3. Vendor homepage
3.2.4. Summary
3.2.5. Icons
3.2.6. Change log for current version
3.3. License
3.3.1. EULA
3.4. Application requirements
3.4.1. Declaring dependencies
3.4.2. Requirements for PHP applications
3.4.3. Requirements for ASP.NET applications
3.4.4. Requirements for Perl applications
3.4.5. Database requirements
3.4.6. Web content requirements
3.5. Package operability
3.5.1. Configuration script
3.5.2. Default installation prefix
4. Gold certification level
4.1. Application and vendor information
4.1.1. Service Summary
4.1.2. Description
4.1.3. Categories
4.1.4. Screenshots
4.1.5. Full change log
4.1.6. Signature
4.2. License
4.2.1. License management
4.3. Localization
4.3.1. Localization attributes
4.3.2. Languages
4.4. Application requirements
4.4.1. Extended database requirements
4.4.2. Extended web content requirements
4.4.3. Operating environment
4.4.4. Virtual container requirements
4.5. Package operability
4.5.1. Extended configuration script
4.5.2. Informative script output
4.5.3. Upgrades
4.5.4. Patches
4.5.5. Backups
4.5.6. Monitoring
4.5.7. Default settings
4.6. Application functionality
4.6.1. Entry-points
4.6.2. Support link
4.6.3. Mandatory function tests
5. Possible future extensions
5.1. Package operability
5.1.1. Setting semantic
5.1.2. Extended informative script output

APS Application Certification has been created to distinguish the appropriately packaged application from ones that do not follow the APS packaging guidelines.

APS application packages, which pass APS Application Certification successfully, receive certificate and permission to use special label and logo.

There are two APS Application Certification levels: Silver and Gold. Informally, the difference between these levels is that Gold applications, the highest level, follow the best practices for APS packaging, while Silver applications comply with mandatory rules only. The formal set of requirements for each level is provided below.

This section provides the generic outline of the APS Application Certification.

The procedure of application package certification requires in-deep package analysis and includes:

  • Validation of package consistency

  • Validation of certification rules according to this document

Gold-level certification assumes paying of fees.

An outcome of a successful certification is an APS Application Certificate of Compliance. The certificate is a digitally signed XML document that is both machine- and human-readable. Certified application package receives permissions to use one of the labels:

"APS 1.2 Silver" or "APS 1.2 GOLD",

and special APS version-depended logo.

We continue to work on improving and evolving the APS Application Certification criteria and process, therefore these document is a subject to change. In order to ensure that applications are up-to-date with the APS Application Certification Criteria, every certificate has a limited validity period. Vendors are encouraged to repeat the certification whenever the requirements are updated. The latest version of this document is always available for download at http://apsstandard.org/.

A Certificate of Compliance is bound to a particular APS Package. In the case of a new version or where an update is issued, it should be certified separately.

An application package is certified as Silver if it satisfies the following requirements:

An application must be packaged according to the APS format specification. That is, every "MUST" and "SHOULD" requirements in specification text must be satisfied.

An application package must contain general information about application and its vendor.

Package metadata must contain URL of the application homepage (application/homepage metadata element).

Package metadata must contain both URL of the packager homepage and complete packager name. An URL must resolve to a page with content-type of either text/html or application/*-xml.

Package metadata must contain both URL of the vendor homepage and complete vendor name. An URL must resolve to a page with content-type of either text/html or application/*-xml.

Package metadata must contain a one-sentence summary of application (application/presentation/summary metadata element). An application summary should not contain line feed characters, and should not be longer than 256 UTF-16 characters (counting surrogate pairs for two chars).

Package metadata must contain an icon for the application (application/presentation/icon/@path metadata element must point to the icon in package). The icon should be of one of the following MIME types:

  • image/gif (not animated)

  • image/jpeg

  • image/png

The image dimensions should be 64x64 pixels.

A package must contain a change log for the current version of application (application/presentation/changelog metadata element).

A package must contain information about application license.

A package must contain text of the license agreement for the services aimed to be provided to end users (application/service/license metadata element).

All resources required by application must be described in metadata file.

If the application needs a resource described in aspect (e.g. PHP or database), it must be declared by supplying aspect-specific requirement in the package metadata.

If a package uses PHP aspect, it must declare which versions of PHP are compatible with the application (php:version requirement element).

If a package users ASP.NET aspect, it must declare which versions of ASP.NET are compatible with the application (aspnet:version requirement element).

If a package users Perl aspect, it must declare which versions of Perl are compatible with the application (perl:version requirement element).

If a package uses database aspect, it must declare default name for each database (db/default-name requirement element), and minimum compatible version of database server for each database (db/server-min-version metadata attribute).

If a package declares using of web content, it must declare an approximate size for each part in the web content description (provision/url-mapping/installed-size metadata element). The actual content size immediately after service provision must not exceed the content size declared by the application metadata.

APS scripts of a package must perform operations they are intended to.

The configuration script must allow installation, configuration and de-installation of the application.

Package metadata must contain a default prefix for installation on domain (url-mapping/default-prefix metadata element).

An application package is certified as Gold if it satisfies the requirements of the Silver certification level, and also satisfies the following additional requirements:

A package must contain detailed information about application and its vendor.

Every declared service must have a summary information. An application and service summary should not contain line feed characters, and should not be longer than 256 UTF-8 characters (counting surrogate pairs for two chars). If a service represents an application user account, it must be declared in metadata (service[class="account"] metadata element).

Package metadata must contain a one-paragraph description of application (application/presentation/description metadata element). An application description must not be longer than 1024 UTF-16 characters, and should not be shorter than 256 UTF-16 characters (counting surrogate pairs for two chars).

Package metadata must contain information about the categories the package belongs to (application/presentation/categories metadata element). The categories used must be as defined in the APS Application Categories document.

A package must contain screenshots for the application (application/presentation/screenshot metadata element). Screenshots must be 640 pixels wide.

A package must contain change log for all released versions of the package (application/presentation/changelog metadata element).

A package must contain content list (APP-LIST.xml file), and must be signed by vendor or packager. The certificate must be valid and acknowledged by certification authority.

A package must contain information about application license.

If the application needs license, it must be declared using license aspect. Every "MUST" and "SHOULD" requirement from the aspect specification must be satisfied.

A package should be friendly to different languages.

For each XML element localizable according to the format requirements, there must be a language-neutral entry (i.e. an entry without an xml:lang attribute).

Package metadata must contain information about the languages supported by the application (application/presentation/languages metadata element).

All resources required by application must be described in metadata file.

If application is capable of sharing database with other applications by using table prefixes, this must be declared in the package by db/can-use-tables-prefix requirement element.

If application declares using of web content and it is able to work with any web server, no certain one must be declared in application metadata. Otherwise, either IIS or Apache aspects must be used.

Operating system-dependent applications must require the environment needed (requirements/env:environment metadata element).

If a package declares PVC aspect using references to external PVC template source, the template checksum must be provided (pvc:checksum metadata element).

A package should provide maximum convenience for APS controller to manage.

The configuration script must allow to enable and disable application.

Verification script must be declared and its output must be structured (metadata element verify-script/structured-output). It must provide error description for controller (error/system element), in case no one for user (error/message) is provided.

If application supports upgrades from previous versions this must be declared in the package by application/upgrade/@match element and the appropriate upgrade operation must be implemented in a configure script.

If application supports updates from previous versions in patch mode, this must be declared in the package by application/patch/@match element.

Application must declare and provide backup/restore functionality, at level the whole application instance could be restored in case of emergency (backup-script element).

Application must provide ability for APS controller to check its heartbeat by declaring resource script (resource-script element). The script must return resource with id="aps-heartbeat" and value="0", if application instance is able to serve requests only.

Application package should contain enough data to be installed in unattended mode. If package defines a mandatory setting for a service, it must also define default value for the setting (setting/@default-value metadata attribute) or declare setting meaning for APS controller (setting/@class metadata attribute). Standard values of the attribute should be used in the last case.

Application instance itself must be consistent.

It must be possible for user to access all application entry points, including those where login credentials are defined (entry/variable metadata element).

Application must declare valid information link to support service site (infolinks/link[@class="support"] metadata element).

The application package must contain at least one test case and its implementation. This test case must be passed by application. The test case must fail if application cannot provide mandatory functions.

This section contains rules that are not yet part of the certification process. Consider these rules as best practices. Future versions of this document may include these rules in as requirements.

Application package must be the most convenient to manage by etalon APS controller.

Application package must declare meaning of a setting for APS controller (setting/@class metadata attribute). Standard values of the attribute should be used.

In case of configuration error caused by the incorrect setting value, verification script output should propose to APS Controller correct value of the one (output/settings/value metadata element).