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

["Grosso, Paul" <pgrosso@ptc.com>]

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.

> -----Original Message-----
> From: Dana Spradley [mailto:dana.spradley@oracle.com] 
> Sent: Thursday, 2007 April 05 18:24
> To: dita@lists.oasis-open.org
> Subject: [dita] regrets, and opposition to including item 
> 12051 as an easy 1.2 fix
> 
> I'm not going to be able to make the next meeting - so in 
> case the "simple/quick fix" list gets compiled at it, I'd 
> like to register my opposition to including item 12051, "Add 
> class attribute to dita element."
> 
> I think this qualifies as a controversial proposal - I 
> believe both myself and JoAnn are on record opposing it.
> 
> Instead of regularizing the dita element and allowing it to 
> be specialized, I'd be more in favor of deprecating it, and 
> eventually eliminating it.
> 
> According to the 1.1 spec, "The <dita> element has no 
> particular output implications; it simply allows you to 
> create multiple topics of different types at the same level 
> in a single document."

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.

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.

> 
> 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