[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] regrets, and opposition to including item 12051 as an easy 1.2 fix
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]