[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Statements of use -- Can you offer one based on the format that Chet outlines?
I'll attach an XHTML version of the 1.3 conformance statement.|
At least one of the three SoUs must come from an OASIS member. You can accept SoUs from non-OASIS members.
The definition of OASIS member is: "a person, organization or entity who is a voting or non-voting member of the corporation, as defined by the OASIS Bylaws." (In the bylaws, if you look, the description is down in Article 12.) So by my reading, an individual member can submit a Statement of Use.
The minimal format for a SoU is:
"<member name> has successfully implemented <committee specification title> Version #.# Committee Specification ## (<link to the spec>) approved <approval date> in accordance with the conformance clauses defined in <section where conformance clauses are defined> <<note here that the wording should either specify "all conformance clauses" or else list/describe the conformance clauses that the implementation satisfies.>> The use of the specification <includes | does not include> interoperation of multiple independent implementations.”
The provider can give more information, but that is the minimal statement. Also, for non-member submissions, the TC can require more supporting information such as links to files, demonstration transcripts, etc.
For OASIS members, the SoU should go to the main TC mailing list. For an Organizational Member, the primary rep must endorse the SoU. If the primary is not a member of the TC, then she/he can just send their statement to whoever is a TC member to forward on.
For non-OASIS members, the SoU must go to the comment mailing list.
The TC must approve a resolution to accept the SoUs.
I think that about covers it.
On Tue, Oct 21, 2014 at 9:27 AM, Kristen James Eberlein <email@example.com> wrote:
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html
TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin
Follow OASIS on:
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
This section outlines the requirements that documents, document types, vocabulary and constraint modules, and processors MUST meet in order to be considered DITA conforming. This section also defines conformance-related terminology and categories.
Conformance to the DITA specification allows documents and document types that are used with different processors or different versions of a processor to produce the same or similar results with little or no reimplementation or modification.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, OPTIONAL in the DITA specification are to be interpreted as described in IETF RFC 2119: Key words for use in RFCs to Indicate Requirement Levels.
The use of these key words and other conformance requirements increase the level of interoperability that is available between DITA conforming implementations. Their use is not meant to impose particular methods on implementers where the method is not required for interoperability.
The key words informative and non-normative identify content that is not normative. The DITA specifications include examples and other suggestions that are informative rather than normative. While informative information is often very helpful, it is never a binding part of the DITA specification even when the example or other information is about a feature that is required. Unless it is clearly stated otherwise, examples and the appendices are always informative rather than normative.
Documents, document types, document type shells, vocabulary and constraint modules, and processors that implement the requirements given in the DITA specification are considered conforming.
Conformance of DITA implementations
A DITA implementation can consist of any combination of processing components that claim DITA awareness, custom vocabulary and constraint modules, and custom document-types shells.
For example, a DITA implementation might be a DITA-based authoring and publishing system within an enterprise; a task-specific product, such a DITA-aware XML editor or component management system;or a set of specialization and constraint modules that are packaged for integration with larger implementations.
Conforming DITA implementations MUST include a conformance statement that gives the version of the DITA specification that is supported. The conformance statement must include one of the following:
Implementations that include some (but not all) DITA features are considered conforming as long as all REQUIRED features relevant to the implementation are included, and all of the features that are included follow the requirements given in the DITA specification.
An implementation that does not include a particular optional feature MUST be prepared to interoperate with other implementations that do include the feature, though perhaps with reduced functionality. An implementation that does include a particular optional feature MUST be prepared to interoperate with other implementations that do not include the feature.
Organizations and individuals can impose additional restrictions on their own use of DITA that go beyond the requirements imposed by the DITA specification. These restrictions can include enforcement of the restrictions by their local processors, as long as the result continues to meet the requirements that are given in the DITA specification. For example, a user community can impose rules on how files must be named or organized, even if those rules go beyond the requirements given in the DITA specification.
Processors that are not DITA-aware (as defined here) are not considered conforming, but such processors might still be useful when working with DITA.
Conformance of documents
A conforming DITA document is a document that meets all of the following criteria:
The use of non-DITA-conforming document type declarations or schemas for conforming DITA documents MUST NOT affect the ability of processors to process those documents. However, the use of non-conforming document types or schemas might impede interchange or interoperation of those documents with tools that expect or require the use of conforming DITA document types or schemas.
Conformation of document types and modules
A conforming document type is a document type that consists only of conforming DITA vocabulary and constraint modules.
A conforming document-type shell is a document type shell that represents a conforming DITA document type and conforms to the requirements for DITA document-type shells.
A conforming vocabulary module is a vocabulary module that conforms to the requirements for its module type.
A conforming constraint module is a constraint module that conforms to the requirements for its module type.
Conformance of processors
The conformance of processors can only be determined for DITA aware processors. We define three types of DITA aware processors:
For example, a general-purpose processor that can process XML documents to produce a
particular output using user-created configurations or scripts is not itself DITA-aware.
However, that same processor packaged with a DITA-specific configuration or script would be
a DITA aware processor. A script or configuration for this processor that only operates on
tag names as defined in specific DITA vocabulary modules would make the tool DITA aware but
not specialization aware. A script or configuration that operated on DITA
A conforming DITA processor is a DITA aware processor that implements all required processing relevant to that processor for the vocabulary modules that it claims to support. A DITA-aware processor MUST support at least one map or topic type, whether defined by the DITA standard or defined as a custom vocabulary module.
A conforming specialization-aware processor is a DITA aware processor that
applies relevant processing to all DITA elements based on their
Note: In general, specialization aware processors will be able to reliably process all conforming DITA documents, providing at least some default behavior for all DITA elements, while DITA aware processors might only be able to reliably process documents that use the vocabulary modules that those processors support.
DITA aware processors support the following functional areas:
A given processor might provide some or all of this function. For example, a DITA aware editor that includes the ability to generate print versions of DITA documents represents both a final-form processor and an editing processor. Likewise, a content or component management system might tightly integrate final-form DITA processors. Each processor type may have different conformance requirements, even though the processors are part of a single product or package.
For processors that produce final form output, all features that are relevant to the type of processing that the processor performs MUST be implemented, with the exception of features that are vocabulary-specific. In particular, such processors MUST implement address resolution and content reference resolution. Such processors SHOULD implement filtering.
For example, a specialization aware processor that produces final-form output need not
provide special presentation results for glossary entry topics, but it must implement
resolution of key-based references to glossary entry topics from
Processors that store, manage, or edit DITA documents might choose to not implement specific features that would be required for final-form processing. However, such processors MUST enable the creation or storage of DITA documents that use all DITA features, even if the processor is not aware of the DITA semantics for those features.
For example, a DITA aware editor need not provide specific support for creating or resolving content references, but it must allow, using normal XML editing methods, the creation and editing of content references. A content management system that supports map types that allow relationship tables but does not directly support relationship table processing must be able to store and manage conforming map documents that include relationship tables.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]