[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] DITA 1.2 terminology
Some background for a discussion of the terminology we want to
use in the DITA 1.2 specification is included below. -Jeff > From: Kristen James Eberlein
[mailto:kris@eberleinconsulting.com] > >
I am going to miss the next two TC meetings, but I don't want to hinder the
resolution of items that pertain to terminology. >
1. Gershon to propose a logical ordering of terms, which he did the following
week. >
>
2. Agenda item for the TC to discuss the following points at a meeting: >
>
* Concrete document type >
> --
Do we need this term? Is it a widely accepted term? >
> --
How is a "Concrete document type" different from a "DITA
document type" >
* The notes in the entry for "Local
shell" are contentious *
Does the terminology apply to entire spec (including Lang Ref topics) or only
specific topics in the spec? >
I've asked Jeff Ogden to "own" the second item in my absence. From Eliot’s 6 November draft rework of the Linking and Addressing
spec. content: Concrete document type A
unique set of structural modules, domain modules, and constraint
modules. Two concrete document types are equivalent if they combine
exactly the same set of modules. A given module set is formally defined as the
value of the @domains attribute on <map>, <topic>, and <dita>
elements. Thus a concrete document type is implied by a given @domains value:
given the @domains value it is conceptually possible to generate a concrete
document type that would correctly validate those documents that use the listed
domains. Because <map>,
<topic>, and <dita> elements must exhibit the @domains attribute,
there is no DITA-defined requirement that DITA documents be literally governed
by concrete document types: every DITA document is inherently governed by the
virtual concrete document type represented by its root element's @domains
value. Concrete document types may be
implemented via document type shells or head schemas. Document type shell (shell
DTD) A
DTD declaration set that implements a concrete document type. The shell
DTD includes and configures one or more structural modules, zero or more
domain modules, and zero or more constraint modules. Shell DTDs may
not declare any element types or attributes directly. Head schema (shell XSD) An
XML Schema document that implements a concrete document type. The head
schema includes and configures one or more structural modules, zero or
more domain modules, and zero or more constraint modules. Head
schemas may not declare any element types or attributes directly. Local shell A document
type shell or head schema that is not a shell provided by a third
party supplying pre-defined DITA modules and shells (e.g., OASIS Open). Local
shells are required in order to create concrete document types that are
different from the OASIS-provided concrete document types. When local shells
are associated with public identifiers, URNs, or absolute URLs, they may not be
associated with the public identifier, URN, or absolute URL of any
OASIS-provided shell. Note: In particular, DITA users should not directly modify
OASIS-provided shells or shells provided by third parties. Note: The simplest local shell is simply an unmodified copy
of an OASIS (or other standard-defined) provided shell, stored in a distinct
location and, if public identifiers are used by documents that use the shell,
bound to one or more distinct and unique public identifiers that reflect the
ownership of the shell by its creator. Note: Because local shells are required in order to modify
any aspect of DITA concrete document types, it follows that any serious use of
DITA should start with the creation of local shells in order to allow immediate
or future adjustment of concrete document types without the need to modify
documents to change their document type declarations or schema location values.
From: Kristen James Eberlein
[mailto:kris@eberleinconsulting.com] I
am going to miss the next two TC meetings, but I don't want to hinder the
resolution of items that pertain to terminology.
I've
asked Jeff Ogden to "own" the second item in my absence. Hi Gershon, Eliot and Dick, thanks for the
feedback. I agree we need to work on the section titles. I wanted to at least
provide something out the door that captures the intent, but I'm not thinking
I've got the section titles 100% accurate. From: Dick Hamilton [mailto:rlhamilton@frii.com] ---------------------------------------------------------------------
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]