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



http://dita.xml.org/blog/25