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


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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

Subject: RE: [dita] related-links content model

Can you provide a use case of the related link problem? Why would I be
using a set of links like this? What is a description of a practical

JoAnn T. Hackos, PhD
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver CO 80215

-----Original Message-----
From: Robert D Anderson [mailto:robander@us.ibm.com] 
Sent: Tuesday, September 27, 2005 4:39 PM
To: dita@lists.oasis-open.org
Subject: [dita] related-links content model

Hello all,

Several groups in IBM are working on specializations and have
the same problem with the related-links content model. Currently, the
(link | linkpool | linklist)+

There must be at least one child. This is a problem when your
specialization should have many optional links, but none can be required
something like this:
<!ELEMENT favoriteAnimals  (favoriteCat?, favoriteBird?, favoriteDog?,
favoriteLlama?, otherAnimalLink*)>

Technically, this is an invalid specialization of related-links, because
none of the links are required - but the users do not want to require
given link from that group. The specialization thus has a looser model
the base, which requires at least one child. The only real way to get
around this is to require a specialized linkpool, which can then contain
all of the optional links.

Are there any problems with changing the plus to an asterisk on the
related-links content model? Doing so would greatly simplify the
specialization of the related-links element. A similar argument can be
for changing the model of lists - Don pointed out to me that the "enote"
demo specialization in the DITA Open Toolkit had this problem, and was
forced to require one specialized list item inside the <noteheader>
element. However, given that my users have not hit this one yet, and
implementations may rely on that required element for processing or
editing, I'm more focused on the link issue.

Any thoughts? Would anybody object to treating these as a bug fixes for
1.1, or as an additional very-simple feature for 1.1? If there are
with changing the model of lists, then what about just updating the
related-links model?


Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit

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