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: some remaining architectural spec questions

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]