dita-lightweight-dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Quick overview of current topic definition with questions for discussion
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: dita-lightweight-dita@lists.oasis-open.org
- Date: Sun, 31 May 2015 21:33:59 -0400
Figuring it might be easier to discuss
something higher level than the actual DTD files...
Here's the current (rough) structure
of the strawman:
Topic specialization/customization
----------
Can be specialized by defining a new
topic element and a body element that incorporates section modules in a
specific sequence/organization. Section specializations are designed to
be easily sharable across topic specializations. Each section specialization
can include further-specialized block elements if needed.
Can be extended by incorporating domains
at the phrase or attribute level.
Attributes and content model behaviors
can be modified by redefining attributes and declaring appropriate constraints:
Out of the box constraints available
are:
- filters - controls whether @props attribute
and any of its specializations are available
- reuse - controls whether @id and @conref
are available on blocks
- variable-content - controls whether
@keyref is available on <ph> , <image>, <data>
- localization - controls whether @dir,
@xml:lang, and @translate are available on most elements
- nested-blocks - controls whether lists
can be nested
Q: in this model, you can easily
share specialized section designs across topic specializations, but you
cannot easily share specialized block-level designs (eg a specialized table)
across section specializations. Is that acceptable? The alternative is
to either open up full domain specialization for blocks as well as phrases,
or create a new method of extension that is parallel to domain extension
but leverages the basic content model entities instead of creating redefinable
entities for every mention of every element.
Q: do we want to open up/doc redefining
other content model entities arbitrarily, eg to add your own elements back
in from base DITA?
Q: do we want to break DITA here, by
allowing the introduction of specialized elements through entity redefinition
as well? What would be the processing model implications?
Q: do we want to also consider breaking
DITA in the way we declare constraints, to make it simpler and more flexible?
For example adding in new elements, just declare them in the constraints
attribute as (+xxx); removing existing elements, same thing but -xxx.
Topic content model
----------
The following common content models
are controlled with entities:
- common-inline: inline text, ph and its
specializations, image, and data
- all-inline: same as common-inline plus
xref, data, and data's specializations
- common-blocks: p, ul, ol, dl, pre, object,
and object's specializations
- all-blocks: same as common-blocks plus
simpletable
- nested-blocks: same as all-blocks (but
only used in the content model of other blocks, so it can be redefined
to turn off block nesting)
Structural elements - all elements have
default class attribute
- topic - requires @id, plus defaulted
values for ditaarch and domains
- title - contains common-inline, has
entity-controlled localization attributes
- shortdesc - contains common-inline,
has entity-controlled localization attributes
- prolog - contains any number of data
elements
- body - contains all-blocks, followed
by any number of sections; has entity-controlled localization attributes
- section - contains optional title, followed
by all-blocks; has entity-controlled localization, filters, reuse
attributes
Block-level elements (except table,
object) - all elements have default class attribute, plus entity-controlled
localization, filters, reuse attributes
- p - contains all-inline
- ul/ol - contains any number of li
- li - contains nested-blocks
- dl - contains any number of dlentry
- dlentry - contains dt, dd
- dt - contains all-inline
- dd - contains nested-blocks
- pre - contains all-inline; has defaulted
xml:space attribute
Table elements - all elements
have default class attribute, plus optional localization, filters, reuse
attributes
- simpletable - contains optional sthead,
any number of strow;
- sthead/strow - contains any number of
stentry
- stentry - contains common-blocks
Object and image elements - all elements
have default class attribute
- object - contains optional desc, followed
by any number of param; has data, type, height, width, name, usemap attributes
plus entity-controlled localization, filters, reuse attributes
- desc - contains common-inline, has entity-controlled
localization attributes
- param - contains nothing, has required
name and optional value attributes
- image - contains optional alt element;
has href, height, width attributes plus entity-controlled localization
and variable-content attributes
- alt - contains common-inline, has entity-controlled
localization and variable-content attributes
Inline elements
- ph - contains all-inline; has entity-controlled
localization and variable-content attributes
- data - contains number data elements;
has optional name/value attributes, plus entity-controlled variable-content
attributes
- xref - contains common-inline; has href,
format, scope attributes, plus entity-controlled localization and variable-links
attributes
Q: object has been defined as an entity
to allow video and audio to be introduced as specializations; do we want
to just ditch object, and go with video/audio from the start?
Q: this list doesn't include <note>
- I know that's been controversial, and I'm open to including it - do we
want to map it to an html5 <aside> element? Maybe even rename it
to that, to broaden its potential usage?
Q: this is using simpletable, elsewhere
I've tried a simplified form of CALS. Does anyone have a preference? Either
way we're not allowing any complex table features - no column spanning,
etc. Maybe we start with simpletable, but allow for the possibility of
people reintroducing full table during customization? I almost wish we
could just go with HTML tables here for the sake of easy mapping to HTML5,
but that would really break all our existing DITA tooling.
Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
mpriestl@ca.ibm.com
http://dita.xml.org/blog/michael-priestley
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]