issues for discussion in specification

[Michael Priestley <mpriestl@ca.ibm.com>]

Compiling draft comments and issues
from the latest revision - if I were clever I'd do this via XSLT. comments
in brackets aren't actually in the source, just stuff I'm noticing during
my pass to extract draft comments.

Terminology - Information type
- Can we really
call a kind of map an information type? I currently think of information
type and topic type as synonyms. 

Terminology - Document type declaration
shell
- This sounds awkward
to me - is there a more elegant way to distinguish between the document
type in abstract versus the actual file instance of the document type?

Specialization concepts - Introduction
to generalization
- copying content
here from the more complete coverage later on, to act as a placeholder.
Maybe rather than have whole topics on generalization, specialization,
information types, maps, etc. in the introduction, we could move those
topics out to the relevant parts of the spec and slim the intro down to
just a definition list, within the terminology section.

Namespace and identifiers 
- (need to incorporate this)

DITA markup
- (linking to children not working because
children are topicheads - add intro topics for sub-branches)

Metadata attributes - audience
- Something in that
last bit must be wrong. If you define the combination in the topic metadata,
why would you need to apply it on a content element. Doesn't it already
apply to the entire topic? Wouldn't you want to use a reference or key
to apply metadata, anyway?

Topics
- I'm not sure what
the following two lines in the outline have to do with topics. Looks like
notes about the DTD structures? Ah, perhaps we need to discuss how the
structure relates to the design.
(probably okay to delete this comment
- just need to clean up outline left from earlier draft)

Information types
- this usage of
information type differs from what we've called out in the terminology
section (where it's used to describe maps as well). We need some decisions
here.

Common DITA map attributes - toc, navtitle,
locktitle
- navtitle should
really be an element for parallelism with the topic metadata. We should
consider changing this to a "prototitle" attribute or something
similar, for the sake of creating a title only for prototyping purposes.
(IE, defining a topic's href and title in the map before it exists, and
then creating a skeleton topic from the information in the map). Probably
a post-1.0 change, but should discuss.

DITA map structure
- could add metadata
at the row level, and collection-type attributes at the column level, to
allow more flexible managament. Post 1.0

Inheritance of attributes and metadata
- (extraneous bullet appearing for some
reason)

Why specialization in content?
- (needs beefing up)

Class attribute syntax
- (should probably move up one level
- single children in a TOC are problematic)
- to discuss from
paul grosso: should we require an ending blank, or is this needless overhead
for the specializer since this could be handled by more intelligent checking
in the XSLT? My (MPs) thought is that both the DTDs and the XSLT are really
outside the domain of the user, and there is a fair chance that a specializer
is also writing XSLT or something similar. So the question is not whether
we can punt to code, but whether the system of dtd+xslt is simpler with
the blank or without the blank - the DTDs and the XSLT are probably being
extended/specialized by the same group of people, so we're not saving them
grief if we make one simpler at the cost of the other, unless there is
indeed a net savings for the system. And in this case, I think the increased
complexity of the XSLT match statement syntax - which is already pretty
scary - outweighs the decreased complexity of the class attribute syntax.

Domains attribute
- I don't think
we actually have a rule for what order they should be listed in, but I
suspect we should have for the sake of making comparisons more reliable.
to discuss from paul grosso: this seems like another needless requirement
on the user, since again the computer/processor could be picking up the
slack. MP: ok, I buy that. removed requirement.

Generalization
- introduced more
of an explanation of "why generalization", per Paul Grosso's
comment, but without creating a complete topic. is this enough?
- what to do with
the domains attribute during round-trip generalization?

Why specialization in design?
- (extraneous bullet)

Integration profiles
- (to be written - do we need/want this
for 1.0?)

Namespaces in design
- (to be written - again, do we need/want
this for 1.0?)

Developing processes
- (to be written)

Using the class attribute
- (really need to integrate this with
XSLT-specific section)

Modularization in CSS - Assembly rules
for CSS
- I am not certain
that CSS fully supports fallthrough in an all-class-based import tree.
During review, we need to test a fully-specialized set of CSS stylesheets
against various user agents and editors and try to characterize the behaviors
a bit.

Namespaces in processing
- (to be written)

This baby is now weighing in at a very
healthy 40 pages. Is this overkill? Should we be looking for places to
cut?

Michael Priestley
mpriestl@ca.ibm.com
Dept PRG IBM Canada  phone: 416-915-8262
Toronto Information Development