RE: [dita] Proposal: "DITA decoration catalog"

Is the desire to get something done within the next month a hope to have this included in the DITA 1.2 spec? If so, I don’t think that is a good idea. This seems like the sort of thing that should have a full proposal and discussion and that makes it a DITA 1.3 issue.

If I can get past the timing issue, I’m not sure what I think of this proposal. The outputclass attribute is pretty loosely defined and its use is pretty application/implementation dependent. And the decorations are pretty formatting/styling based. So I wonder if they really belong in the spec. If it does belong in the spec., perhaps there needs to be some other more formal way (new attribute, new elements) to do it so as not to overload outputclass with a mix of standards based and ad hoc uses. And, finally, this feels a little like it might be/should be related to the flagging part of filtering and flagging. For that it is pretty easy to add new multi-valued conditional processing attribute specializations based upon props. If that approach is viable, the discussion would change to one about how you specify the different “decorations” in the ditaval file.

-Jeff

From: Park Seth-R01164 [mailto:seth.park@freescale.com]
Sent: Monday, September 21, 2009 5:00 PM
To: dita
Subject: [dita] Proposal: "DITA decoration catalog"

I'm giving my users the ability to define non-semantic decorations using outputclass. I do this with reservation, but I'm convinced that we'll see more of this kind of request in the near future.

I'd like to request that we provide a "DITA decoration catalog" of outputclass values that should be meaningful across local systems yet customizable for local requirements.

I've captured a sample implementation of such a catalog at http://wiki.oasis-open.org/dita/DITA_Decorations.

Anybody else confronted with this demand?

I need to roll out something within the next month. Any chance of resolving an initial list of standard outputclass values before then?

-seth park

dita message