RE: [dita] regrets, and opposition to including item 12051 as an easy 1.2fix

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

"Grosso, Paul" <pgrosso@ptc.com> wrote
on 04/06/2007 10:21:09 AM:

> I could be missing some details, and I expect someone
> like Michael to correct me if I'm wrong, but let me
> explain things the way I understand them.

I'm late to my cue, but I'll add some thoughts.

> More accurately, it currently allows you to put topic, task,
> concept, and reference together in a single document.  It
> does not allow you to put other topic-level things that you
> may have created as specializations of topic.  That's the
> problem.

The <dita> element was originally intended to
be a bucket for holding any kind of topic type - so it could be used in
any shell document type to assemble any number of different topic types.
I think we're running into one of those legacy problems with the language
spec being adapted from a language reference, so content that was once
merely descriptive (this is what it does for the 1.0 doctypes) has become
prescriptive (this is what it must do for any doctype).

There's no processing associated with the element
explicitly because it was a bucket with unknown content. 

> 
> When we create a new generalized topic (or whatever we are
> calling it) in DITA 1.2, it will not be able to be put into
> a ditabase document (unless we change the dita element's 
> content model specially for the element we add).
>
> The point is that any user that creates a new specialization
> of topic isn't going to be able to put those new elements
> into a ditabase document unless they can create a specialization
> of the dita element.

The dita element is actually declared in the shell
doctype, rather than in a module, so that its content model can be controlled/declared
in the shell, rather than in a module. In other words, its content model
is expected to be different in different doctypes, without using specialization.
Since there is no processing associated with the dita element, there is
nothing to inherit from specialization, and nothing to break by changing
its content model for new authoring contexts.

That said, nesting of topic types in general, as well
as containment of topic types under <dita>, is controllable without
specialization generally. The info-types entity, and its type-specific
equivalents, can be redefined in shell document types without requiring
specialization: I can create my own doctype that says concepts nest tasks,
for example, purely by manipulating the shell and without declaring new
elements. 

So in this respect, the behavior of the <dita>
element (you can add new topic types to its content model without requiring
specialization) is already consistent with the control of topic type containment
elsewhere in the model.

> > As such, it needs no class attribute - since the sole 
> > function of that attribute is to preserve output implications
> > across specializations.
> 
> I'm not sure what "preserve output implications across 
> specializations" means, but the function of the ditabase
> document type (and hence the dita element) is to allow a
> user to collect various topic-level elements into one
> document.
> 
> And they can't include their own topic-specializations
> in a ditabase document as things stand.
> 
> > 
> > To add a class attribute to the dita element and make it 
> > available for specialization is a major architectural change
> > that requires careful thought, not a simple easy fix.
> 
> I don't see how allowing specialization on the one DITA element
> that currently does not allow it as a major architectural change.
> 
> paul

I think that the current documentation for the dita
element is unclear - I'd like to correct it for 1.1 to make its purpose
as a general-purpose aggregator more explicit. The architectural spec would
need an explicit mention of the <dita> element in the design pattern
section, effectively saying that you just copy it over into the doctype
shell. And we could add a clarifying paragraph to the language spec as
well. But given that specialization is not necessary to change the content
model, I'm not sure that we'd want to make it specializable - it would
imply that it should be processable, which in turn would be a major change,
so I share Dana's concern in that regard.

Michael