Re: content model for LwDITA <linktext>?

[Kristen James Eberlein <kris@eberleinconsulting.com>]

Guys, this discussion should be on the official OASIS list. My apologies for not noticing that earlier

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)

On 5/30/2017 8:24 AM, Carlos Evia wrote:

I agree... sounds advanced for LwDITA. See attached image. 

-- 

Carlos Evia, Ph.D.

Director of Professional and Technical Writing

Associate Professor of Technical Communication

Department of English

Center for Human-Computer Interaction

Virginia Tech

Blacksburg, VA 24061-0112

(540)200-8201

On Tue, May 30, 2017 at 8:19 AM, Kristen James Eberlein <kris@eberleinconsulting.com> wrote:

I'm thinking that the use case Alan mentions in the 2nd paragraph is fairly advanced and something that we don't need to account for. Others?

Kris

Sent from my iPad

On May 30, 2017, at 8:13 AM, Alan Houser <arh@groupwellesley.com> wrote:

All good. I'm thinking of the use case "My company/product name contains {superscript/bold/italic}". But you can accomplish that with <ph>.

However, <ph> would not support the use cases of "I want to manage {inline icons/xrefs} with keys". Unless I'm missing another way to define key bindings in LwDITA.

-Alan

On 5/30/17 8:02 AM, Kristen James Eberlein wrote:

We can always relax the content model later, if there is need, but of course we cannot tighten a content model once released without breaking backwards compatibility.

For these reasons, I usually go with the tightest content model for the first release/prototype/whatever.

Interested in hearing what others think.

Kris

Sent from my iPad

On May 30, 2017, at 7:58 AM, Kristen James Eberlein <kris@eberleinconsulting.com> wrote:

With LwDITA, we are going for restrictive content models. Can you think of reasons why LwDITA authors would need more than ph? Limiting link text to ph will make it easy for vendors to automatically present a very easy way for authors to define keys for variable text.

Kris

Sent from my iPad

On May 30, 2017, at 7:54 AM, Alan Houser <arh@groupwellesley.com> wrote:

I could support just <ph>; no text. So <ph> would essentially be a required child of <linktext>?

Are there any reasons to favor "just <ph>" over a mixed content model?

-Alan

On 5/29/17 10:36 PM, Kristen James Eberlein wrote:

How about just ph?

Kris

Sent from my iPad

On May 29, 2017, at 9:59 PM, Alan Houser <arh@groupwellesley.com> wrote:

Sending this to the attendees of today's LwDITA meeting...

What's our intention for the content model of <linktext>? DITA 1.3 specifies:

(#PCDATA | <b> | <data> | <data-about> | <foreign> | <i> | <keyword> | <line-through> | <overline> | <ph> | <sort-as> | <sub> | <sup> | <term> | <text> | <tt> | <u> | <unknown>)*

I presume we will treat <linktext> as an inline element and permit mixed content. LwDITA candidates include:

<!ENTITY % common-inline  "#PCDATA|%ph;|image|%data;">
<!ENTITY % all-inline  "#PCDATA|%ph;|image|xref|%data;">

Of course, "%ph;" also includes the inline typography domain elements carried over from DITA ("(b | i |u | sup | sub)").

I favor the "%all-inline;" set. Other opinions or suggestions?

-Alan

-- 
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532