OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita] Element Type Names Don't Matter--Class Is Everything


"JoAnn Hackos" <JoAnn.Hackos@Comtech-Serv.com> wrote on 08/04/2004 11:07:14 AM:

> I am certainly not an expert on the technical aspects of DITA.
> However, I'd like to comment on the issue Eliot raises of element
> names. In many organizations, the authors need to place metadata at
> the element level to distinguish among content for different
> deliverables. For example, authors may need to create three versions
> of a step in a procedure in order to specify content for three
> different versions of equipment.
>
> In the processing, how will these variations on content within a
> topic be addressed?

The current mechanism for conditional views still applies: use any of the %select-atts; attributes (@platform, @product, @audience, @otherprops) to associate a meaningful metadata key, and do selective processing (filtering or flagging) based on matching that value.

I don't think that Eliot's proposal affects this conditional processing based on metadata.  The issue of reflecting metadata into the authoring environment is mainly one of editor support for rendering attributes in a view.  Most style mechanisms in editors will allow reflecting an attribute value into the formatted view of a step.  But a stylesheet written to show such metadata would be more of a task-supportive view than a WYSIWYG view.  Most users prefer to think they could work entirely in WYSIWYG mode, but the task-supportive views are actually a productivity aid in that power users can see (and ideally work directly with) the metadata that really establishes the behavior of the content they are working with.

Although the TC is not necessarily required to develop best practices for authoring views in editors, I think its a useful test point for us to ask how DITA features affect the ability of editors to support those features.  I remind tools developers to continue weighing this ongoing design discussion on whether the mechanisms are supportable, since the spec needs to be accompanied (er, vindicated?) by working implementations.

Regards,
--
Don Day <dond@us.ibm.com>
Chair, OASIS DITA Technical Committee
IBM Lead DITA Architect
11501 Burnet Rd., MS 9037D018, Austin TX 78758
Ph. 512-838-8550 (T/L 678-8550)

"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]