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


Help: OASIS Mailing Lists Help | MarkMail Help

dita-lightweight-dita message

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

Subject: Re: content model for LwDITA <linktext>?

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


Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
+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

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?


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.


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.


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.


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?


On 5/29/17 10:36 PM, Kristen James Eberlein wrote:
How about just ph?


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 Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter

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