[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Jeff's (Arbortext) DITA 1.1 Language Ref comments...
Robert, I would welcome a general table of the contains/contained by for each of the doctypes. That would be easier to review than the embedded information in the elements. 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, January 23, 2007 8:53 AM To: dita@lists.oasis-open.org Subject: Re: [dita] Jeff's (Arbortext) DITA 1.1 Language Ref comments... Hi Paul - > The statement "Note: The actual contains or contained-by information > displayed here may differ slightly, depending on whether the element > is used in a map, bookmap, stand-alone topic, or composite file > (ditabase)" appears on many more elements than I expected (I expected > it on topic, task, concept, and reference). I was also startled to see how often it popped up. The main reason for this actually came from domains, rather than from topic types. For example, the keyword element may appear in many places within a topic, including inside the <b> element. Keyword can also be used inside maps; however, maps do not have the highlighting domain, so <b> is not available. Thus, the model differs between maps and topics. Likewise, anything that can contain keywords and appears in both maps and topics will have this problem -- in maps, <ph> does not contain domain specializations like wintitle, while in topics it does. Similarly, common body elements get this message because they may be in (body | conbody) within ditabase, but only <body> when in the single topic type. Many of them may also appear in maps through some twisted nesting, which results in the domain problem again. I'm certainly open to better wording, if anybody would like to suggest some. Given that the contains/contained by only applies to the supplied OASIS doctypes, and could change with any specialization, it might be best to give this a more complex description at the end, and turn the note into a link. "This describes the contains/contained-by information for a composite ditabase file. See [this page] for information on other content models." Another option might be to just give the caveat on topic-level elements; however, I know that several of my own users have reported bugs on our documentation, caused by reuse of the OASIS contains/contained-by information for phrase level elements. Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit (507) 253-8787, T/L 553-8787 "Grosso, Paul" <pgrosso@ptc.com> wrote on 01/23/2007 09:12:35 AM: > ...form too big an attachment for the OASIS mailer, so I'm sending > them to Don separately. > > Here is the cover message: > > -----Original Message----- > From: Grosso, Paul > Sent: Tuesday, 2007 January 23 08:54 > To: dita@lists.oasis-open.org > Subject: Jeff's (Arbortext) DITA 1.1 Language Ref comments > > This message has a large attachment (comment-laden PDF), so I'm not > sure if it will get through to the list, but I'm giving it a try. > > Lots of comments, but nothing too serious beyond our reservations on > ditaval and chunk mentioned earlier. ditaval doesn't appear anywhere > in the Language Reference, although if it is going to be part of the > standard, I think it should. > > I've sent separate email about missing information related to the > scale, height and width attributes on image and object. > > The statement "Note: The actual contains or contained-by information > displayed here may differ slightly, depending on whether the element > is used in a map, bookmap, stand-alone topic, or composite file > (ditabase)" appears on many more elements than I expected (I expected > it on topic, task, concept, and reference). I haven't checked it > against the DTD or schema, but Robert is pretty careful so I suspect > it is right. But having it appear so often weakens the standard in my > opinion. Not sure what to do about it. It might be possible to list > the different information explicitly for the different contexts. The > need for this statement in so many places may be an indication that we > are making a mistake in the definition of the DITA content model. > > paul (and Jeff)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]