RE: [dita] related-links content model

[Robert D Anderson <robander@us.ibm.com>]

Hi,

This has become a problem for a couple of groups working on different
specializations. One user needs the following links:
* one optional link to setup information for the topic
* one optional link to a zip that contains materials related to the topic
* one optional link to in-depth information about this topic
* one optional link to a PDF version of the topic
* any number of links to bio topics about the authors
* any number of generic links

Ideally, the content model would look something like this:
(setupLink?, downloadMaterials?, inDepthInfo?, pdfVersion?, authorInfo*,
link*)

As explained previously, this is not allowed, because nothing is required.
The only way to get around this without making one required is to
specialize a linkpool, and make that required - something like this:
<newLinks><newLinkPool> ...optional links, in order...
</newLinkPool></newLinks>

Instead of having the overhead of 2 link groups, this user chose not to
enforce an order, and allow any number of links:
(setupLink | downloadMaterials | inDepthInfo | pdfVersion | authorInfo |
link)+

This does not really meet her needs, because most of the links should be
limited to one instance.

The other user wants to have a related links element to include
contact/support information. He set up the model like this:
(email*, emailcc*, url*)

This one is easier to fix, just by removing the order requirement, but it
does mean the user does not get exactly what he wants.

Aside from the actual use cases - I can vouch for the fact that it is
difficult to explain to users why their new templates must have either one
required link, or a seemingly useless element...

Thanks,

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


                                                                           
             "JoAnn Hackos"                                                
             <joann.hackos@com                                             
             tech-serv.com>                                             To 
                                       Robert D                            
             09/29/2005 02:32          Anderson/Rochester/IBM@IBMUS,       
             PM                        <dita@lists.oasis-open.org>         
                                                                        cc 
                                                                           
                                                                   Subject 
                                       RE: [dita] related-links content    
                                       model                               
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi,
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
situation?
JoAnn

JoAnn T. Hackos, PhD
President
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver CO 80215
303-232-7586
joann.hackos@comtech-serv.com

-----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
encountered
the same problem with the related-links content model. Currently, the
model
is
(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
any
given link from that group. The specialization thus has a looser model
than
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
made
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
some
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
problems
with changing the model of lists, then what about just updating the
related-links model?

Thanks,

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