Hi Ian and everyone
The main output of this subcommittee is now meant to be
recommendations on changes to the DITA specification. However, I think we
should be testing whether claims that we make about something being possible
for DITA publishing tools to incorporate, and I feel that the DITA OT is a good
“proving ground”. While we may publish the results of our testing
and experimentation, we have to be careful about not being seen to recommend
the DITA OT over rival tools.
So while we may use DITA OT for our experimentation (and your
@actions idea is something we should pursue, even though it might have broader
application than just UA), we won’t be using it as a “reference
implementation”. This approach (test bed rather than reference
implementation) might address some of Chris’s concerns about DITA OT
bias... what do you think of this as an approach, Chris?
I agree that we have to be careful not to just overload
attributes with bodgied-up semantics, but if an existing element or attribute
can be applied to a UA-specific application without bending anything, I think
that’s perfectly valid.
Cheers
Tony
From: ian balanza-davis
[mailto:]
Sent: Friday, 4 September 2009 5:42 PM
To: ;
Subject: Re: [dita-help] Groups - New Action Item #0001 Consult the
DITA-OT contribution...
I think it is the difference between
providing a plug-in or example for the demonstrations by overloading attributes
that currently exist in DITA (to achieve the expansion links through javascript
for example), and a new attribute or attribute group (or metadata, since DITA
seems to have an odd idea of what can be metadata) that provide implementors
with a hook from which to produce their own version.
In my opinion, without a reference implementation as a method of showcasing
ideas, we are pushed more to the latter. The benefit is that we may be able to
provide a way that moves beyond help systems.
For example, if elements contain something like @actions -- a list of
javascript functions -- that could be used both within and outwith a help
system.
Ian
