dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] Proposal: Allow <xref> within <shortdesc>
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: Kristen James Eberlein <kris@eberleinconsulting.com>
- Date: Tue, 11 Sep 2012 10:35:45 -0400
Hi Kris,
I don't think adding xref to shortdesc
really increases complexity - it actually removes a wrinkle in the content
model that has caused questions. In other words, by adding the element
we increase consistency, which decreases complexity.
If we wanted to continue the ban on
links in shortdesc that existed in DITA 1.0, we'd need to not only constrain
shortdesc to remove xref, but also constrain ph and keyref in the context
of shortdesc (if that were possible, which it isn't, at least with DTDs).
I don't think that's realistic - so we're going to have to accomodate linking
anyway. The only question is whether we accomodate it in a consistent manner
(including xref) or an inconsistent manner (including xref in ph, and keyref
on keyword/cite/etc, but excluding xref in shortdesc).
I think if we allow <cite> in
shortdesc we're alread going to see wording like "See xxx for more
info" appearing in shortdesc-derived hoverhelps. If some of those
"xxx"s are actually sourced from an xref instead of a cite, does
it matter?
Michael Priestley, Senior Technical Staff Member (STSM)
Total Information Experience (TIE) Technology Strategist
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
From:
Kristen James Eberlein
<kris@eberleinconsulting.com>
To:
Eliot Kimber <ekimber@rsicms.com>,
Cc:
dita <dita@lists.oasis-open.org>
Date:
09/11/2012 09:59 AM
Subject:
Re: [dita] Proposal:
Allow <xref> within <shortdesc>
Sent by:
<dita@lists.oasis-open.org>
Eliot, I knew that you and I would disagree on this
issue. I'll be
interested to see what other folks who work primarily with an end-user
base have to say.
While I'd like to agree that our primary user group of concern is
"specializers" and "implementers," I think that for
the DITA 1.x-level
releases we have a responsibility to look out for other communities,
including authors.
DITA 1.0 and DITA 1.1 were relatively simple and the spec relatively
short. With DITA 1.2, we added a lot of complexity -- some of which we
are just beginning to unravel and sort out -- and the spec became much
more inaccessible. I think we need to do a balancing act for the 1.x
releases.
For this instance, simply constraining <xref> from the concept, task,
and reference shells might be an adequate answer. This might mean
another item for our DITA 1.3 proposal templates; for changes that will
affect the base vocabulary, do we need to add constraints to other
TC-provided shells?
--
Best,
Kris
Kristen James Eberlein
Principal consultant, Eberlein Consulting
Co-chair, OASIS DITA Technical Committee
Charter member, OASIS DITA Adoption Committee
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)
On 9/11/2012 9:23 AM, Eliot Kimber wrote:
> On 9/11/12 6:54 AM, "Kristen James Eberlein" <kris@eberleinconsulting.com>
> wrote:
>
>> Given the role of the <shortdesc> for hover text and auto-generated
link text,
>> I think adding <xref> is inappropriate.
> Our point was that since you can already have links in shortdesc and
thus
> processors need to account for them in hoverhelp or whatever, adding
<xref>
> doesn't change the problem.
>
> It is important to keep in mind that, at the base vocabulary level,
our
> primary concern must be *specializers*, not authors. Authors are served
by
> configured and specialized document types and it is certainly easy
to
> constrain away xref if you do not want to allow it in <title>
in your
> environment.
>
> But if there is *even one* legitimate requirement for xref in shortdesc
(and
> I certainly have that requirement in the Publishing space), then I
contend
> we *must* allow it in the base content model for shortdesc.
>
> If we want to provide constraint modules for concept/task/reference
that
> constrain xref out of shortdesc, I'm fine with that and will volunteer
to
> define the constraints and update the TC-provided shells.
>
> But one of the historical problems with DITA as a base for wide use
is that
> many content models are over-constrained, disallowing satisfaction
of
> legitimate requirements in order to reflect the practice of a specific
user
> community.
>
> We have to stop doing that.
>
> Cheers,
>
> E.
--
Best,
Kris
Kristen James Eberlein
Principal consultant, Eberlein Consulting
Co-chair, OASIS DITA Technical Committee
Charter member, OASIS DITA Adoption Committee
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)
---------------------------------------------------------------------
To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: dita-help@lists.oasis-open.org
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]