← Prev in month
← Prev in thread
Next in thread →
Next in month →
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 <>
To:
Kristen James Eberlein <>
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 <>
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 <>
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.
← Prev in month
← Prev in thread
Next in thread →
Next in month →