dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: some remaining architectural spec questions
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: dita@lists.oasis-open.org
- Date: Wed, 20 Dec 2006 00:07:39 -0500
1) should we deprecate the grouped
value syntax for conditional property values in otherprops?
pro: we now have a way to group values
by adding new attributes, which makes this workaround unnecessary
con: sometimes you need to manage complex
conditions without having time to change the doctype
options: a) leave it documented as-is,
b) deprecate in favour of adding new attributes, or c) just recommend using
new attributes
2) should we remove a forward-looking
statement about domains?
current wording:
>>
With the exception of the common base
modules (topic and map), a domain cannot
be specialized from a structural type.
For example, a domain cannot be specialized
from elements in <task>, only
from the root structural modules for <topic>
or <map>. This rule ensures
that domains can be integrated and document
types can be generalized predictably.
The rule may be relaxed in future versions
of DITA if a mechanism is added for
tracking dependencies between structural
and domain specializations in use
by a document type.
>>
Should we remove the last sentence?
3) should we remove a reference to
architectural forms?
the description of the class attribute
describes how it differs from architectural forms. is this positioning
necessary for our audience?
current wording:
>>>
The class attribute tells a processor
what general classes of elements the
current element belongs to. It's
something like an architectural forms attribute,
except that it contains multiple
mappings in a single attribute, instead
of one mapping per attribute.
Also, DITA scopes values by module type (for
example topic type, domain type, or
map type) instead of document type, which
lets us combine multiple topic types
in a single document without complicating
transform logic.
>>>
4) catalogs and public identifiers
should we add these to the spec?
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]