OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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.

Kris

----
Subject: Re: Statements of use (Was "Re: How to cite XNAL standard as a non-normative reference in the DITA spec")
Date: Tue, 21 Oct 2014 10:28:23 -0400
From: Chet Ensign <chet.ensign@oasis-open.org>
To: Kristen James Eberlein <kris@eberleinconsulting.com>


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. 

/chet



On Tue, Oct 21, 2014 at 9:27 AM, Kristen James Eberlein <kris@eberleinconsulting.com> wrote:
Thanks!
On a different note -- Can you provide me with more information about what is required for statements of use? And I assume that an organizational member is an OASIS member that is NOT an individual member; let me know if I am making an incorrect assumption.

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)

On 10/21/2014 9:14 AM, Chet Ensign wrote:
Let me look into this Kris. I'll get back to you with an answer - this one is old and I need to do some digging... 

/chet

On Mon, Oct 20, 2014 at 7:35 PM, Kristen James Eberlein <kris@eberleinconsulting.com> wrote:
Can you provide me with a citation? I could not find an on-line version of the specification.
--
Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)




--

/chet   [§] 
----------------
Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

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:
LinkedIn:    http://linkd.in/OASISopen
Twitter:        http://twitter.com/OASISopen
Facebook:  http://facebook.com/oasis.open




--

/chet   [§] 
----------------
Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

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:
LinkedIn:    http://linkd.in/OASISopen
Twitter:        http://twitter.com/OASISopen
Facebook:  http://facebook.com/oasis.open


--------------------------------------------------------------------- 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

Title: Conformance

Conformance

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.

Key words

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.

Conformance statement

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

Draft comment: Kristen Eberlein 16 November 2013
Content present in DITA 1.2 spec, but reorganized into a section to impose parallelism.

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:

  • List of the DITA features that are supported by the implementation in accordance with the requirements of the DITA specification
  • Statement that the implementation includes all features except for a specific list of features that are not supported in accordance with the requirements of the DITA specification

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:
  • It is a well-formed XML document.
  • Its elements either are DITA elements or non-DITA elements that are contained within <foreign> or <unknown> elements.
  • Its content conforms to all DITA requirements for element content and attribute values.
  • If the document has a document type declaration or an associated XSD, the referenced document type or XSD is a conforming DITA document-type shell.

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:

  • A DITA aware processor is a processor that can handle documents conforming to at least one conforming DITA document type, as specified by the processor, but need not support any features not required by that document type.
    Draft comment: Kristen Eberlein 16 November 2013
    Is the clause "as specified by the processor needed"? What does it add?
  • A specialization aware processor is a DITA aware processor that can handle any document specialized from some set of supported vocabulary modules and with, possibly, the required use of specific constraint modules.
    Draft comment: Kristen Eberlein 16 November 2013
    Why "some set of supported vocabulary modules"? Can we change this to "a set"? What do we mean by "and with, possibly, the required use of specific constraint modules"?
  • A fully aware processor is a DITA aware processor that unconditionally supports all base vocabulary modules, which implies support for all non-vocabulary-specific DITA features, such as content references and key references.

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 @class attribute values would be both DITA aware and specialization aware.

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.

Draft comment: Kristen Eberlein 16 November 2013
Should this be changed to read "that applies relevant processing for the vocabulary modules that it claims to support"? Parallelism with the next term definition.

A conforming specialization-aware processor is a DITA aware processor that applies relevant processing to all DITA elements based on their @class and @domains attribute values.

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:

Production of output
The production of final form output from DITA documents. Examples of processors that perform this function are publishing systems and tools, such as the DITA Open Toolkit.
Editing, managing, and storage
The editing, managing, and storage of DITA documents. Examples of processors that perform this function are authoring tools and component content management systems (CCMs).

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 <keyword> or <term> elements, because address resolution is both required and not vocabulary specific.

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]