Re: [dita] Proposal: Allow <xref> within <shortdesc>

From
Michael Priestley <>
Date
2012-09-11T14:44:00+00:00
ID
Thread
Re: [dita] Proposal: Allow <xref> within <shortdesc>
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



http://dita.xml.org/blog/25

From:      
 Kristen James Eberlein
<>

To:      
 Eliot Kimber <>,

Cc:      
 dita <>

Date:      
 09/11/2012 09:59 AM

Subject:    
   Re: [dita] Proposal:
Allow <xref> within <shortdesc>

Sent by:    
   <>

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" <>

> 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: 

For additional commands, e-mail: