If an SMDL document
NOTE 60
The provisions of this International Standard allow wide latitude in choosing which constructs SMDL to support.
NOTE 61
Conformance to SMDL is independent of whether the document also conforms to a document architecture.
12.2 Conforming SMDL application
12.2.1 Application conventions
A conforming SMDL application's conventions can affect only areas that are left open by this International Standard to specification by applications .
NOTE 62
E.g., the generic identifiers of element types conforming to SMDL and SMDL architectural forms may be chosen ad libitum, but thevalues of SMDL attributes can only be changed if the SMDLNms attribute is used as specified in this Interna-tional Standard.
12.2.2 Conformance of documents
A conforming SMDL application shall require its documents to be conforming SMDL documents, and shall not prohibit any markup that this International Standard would allow in such documents.
NOTE 63
For example, an application markup convention could recommend that only certain minimization functions be used, but could not prohibit the use ofother functions if they are allowed by the formal specification.
12.2.3 Conformance of documentation
A conforming SMDL application's documentation shall meet the requirements of this Inter national Standard (see Section 12.5).
If an SMDL system
NOTE 64
Whether a system is a conforming SMDL system is not affected by whether it is also a conforming implementation of a document architecture.
12.3.1 Conformance of documentation
A conforming SMDL system's documentation shall meet the requirements of this International Standard (see Section 12.5).
12.3.2 Conformance to SMDL system declaration
A conforming SMDL system shall be capable of processing any conforming SMDL document that is not inconsistent with the system's SMDL system declaration (see Section 12.6).
NOTE 65
A system's inability to process data content notations that are not defined in this International Standard does not affect whetherit is a conforming SMDL system.
12.3.3 Application conventions
A conforming SMDL system shall not enforce application conventions as though they were requirements of this International Standard.
NOTE 66
Warning of the violations of application conventions can be given, but they must be distinguished from reports of SMDL errors.
If an SMDL engine in a conforming SMDL system meets the requirements of this sub-clause, it is a validating SMDL engine.
NOTE 67
A conforming SMDL system need not have a validating SMDL engine. Implementers can therefore decide whether to incur the overhead of validation in a given system. A user whose multimedia authoring system allows the validation and correction of SMDL documents, for example, will not need to repeat the validation process when the documents are rendered by a processing system.
A validating SMDL engine shall find and report a reportable SMDL error if one exists, and shall not report an error when none exists.
A validating SMDL may optionally report other errors.
NOTE 68
This International Standard does not specify how an SMDL error shold be handled, be y ond the requirement for reporting it. In particular, it does not state whether the erroneous information should be treated as data, and/or whether an attempt should be made to contin ue processing afteran error is found.
NOTE 69
This International Standard does not prohibit avalidating SMDL engine from reporting an error that this International Standard considers non-reportable if the engine is capable of doing so. Neither does it prohibit an engine from recovering from such errors, not does it require an engine to report them when it is not performing validation.
A validating SMDL engine may warn of conditions that are potentially, but not necessarily , errors.
NOTE 70
SMDL architectural forms do not constrain the construction of document type definitions, only document instances. However, avalidating SMDL engine can optionally report DTD constructs that would prevent the creation of avalid conforming instance, or that would allow the creation of a nonconforming instance.
12.4.2 Identification of SMDL messages
Reports of SMDL errors, including optional reports, shall be identified as SMDL messages in such a manneras to distinguish them clearly from all other messages, including warnings of potential SMDL errors.
12.4.3 Content of SMDL messages
A report of an SMDL error, including an optional report, shall state the nature and location of the error in sufficient detail to permit its correction.
NOTE 71
This requirement is worded to allow implementers maximum flexibility to meet their user and system requirements.
12.5 Documentation requirements
The objectives of this International Standard will be met most effectively if users at all levels are aware that SMDL documents conform to an International Standard that is indepenedent of any application or engine. The documentation of a conforming SMDL system or application shall further such awareness.
NOTE 72
These requirements are intended to help users apply knowledge gained from one SMDL system to the use of other systems. They are not intended to inhibit a casual and friendly writing style.
12.5.1 Standard identification
Standard identification shall be in the natural language of the documentation. Standard identification text shall be display ed prominently:
For applications, the identification is:
For systems, the identification is:
The documentation for a conforming SMDL system shall include an SMDL system declaration (see Section 12.6).
12.5.2 Identification of SMDL constructs
The documentation shall distinguish SMDL constructs from application conventions and system functions, and shall identify the SMDL constructs as being part of the Standard Music Description Language.
NOTE 73
The objective of this requirement is for the user to learn which constructs are common to all SMDL systems, and which are unique to this one. This will reduce the experienced user's learning time for a new system or application.
This International Standard shall be cited as a reference for supported SMDL constructs that are not specifically documented for the system or application. For example, if, for simplicity's sake, only a sub-set of some function is presented (such as by omitting some of the options of the extent reconciliation strategy element type form), it shall be stated clearly that other options exist and can be found in this International Standard.
All SMDL constructs shall be introduced using the terminology of this International Standard, translated to the national language used by the publication or program. Such standard terminology should be used thoughout the documentation. If not with standing, a non-standard equivalent is used for a standard term, it must be introduced in context and it shall not conflict with any standard SMDL terms, including terms for unsupported or undocumented constructs.
An SMDL system declaration specifies the version of SMDL and all of the facilities that an SMDL system can support.
NOTE 74
The system declarataion for a system that supports all of the modules and optional facilities of SMDL is given in Section 11.2.1.
[ Index | Previous Paragraph ]