[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: AW: AW: [dita] Groups - DITA Proposed Feature #12021: Nesting sections (12021.html) uploaded
>>I agree with you that the proposal name is confusing, and hopefully that might help to clarify things Sheesh! My brain was working faster than I could type: What I meant to say was that by changing the proposal name might help to clarify things. Hopefully, this clarifies my clarification. Jim ================ Jim Earley XML Architect/Consultant Flatirons Solutions 4747 Table Mesa Drive Boulder, CO 80301 Voice: 303.542.2156 Fax: 303.544.0522 Cell: 303.898.7193 Yahoo.IM: jmearley MSN.IM: jearley22@hotmail.com jim.earley@flatironssolutions.com -----Original Message----- From: Earley, Jim Sent: Tuesday, October 30, 2007 10:34 AM To: 'Eliot Kimber'; dita Subject: RE: AW: AW: [dita] Groups - DITA Proposed Feature #12021: Nesting sections (12021.html) uploaded Eliot, I agree with you that the proposal name is confusing, and hopefully that might help to clarify things . It may also help if I add some additional content related to the fact that DITA already has a mechanism for supporting nested formal (titled) content in the form of nested topics, and that this proposal is clearly about adding containers for organizing content, which has the out-of-the-box benefit for conref and conditional processing and is a welcome structural component for enabling specializations that have a nested structural requirement. Thanks, Jim ================ Jim Earley XML Architect/Consultant Flatirons Solutions 4747 Table Mesa Drive Boulder, CO 80301 Voice: 303.542.2156 Fax: 303.544.0522 Cell: 303.898.7193 Yahoo.IM: jmearley MSN.IM: jearley22@hotmail.com jim.earley@flatironssolutions.com -----Original Message----- From: Eliot Kimber [mailto:ekimber@reallysi.com] Sent: Tuesday, October 30, 2007 10:13 AM To: dita Subject: Re: AW: AW: [dita] Groups - DITA Proposed Feature #12021: Nesting sections (12021.html) uploaded On 10/30/07 10:16 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote: > OK - so for legacy content that has not been chunked into topics, they > still want to enforce the one topic per file constraint they have decided > on, but without rewriting the content to match? > > The obvious option within the architecture is to combine the "senseless > small crumbs" into one file for authoring, until it is ready to split out > properly. A policy of exactly one file per topic is not an appropriate or sustainable policy for the simple reason that DITA requires that you use nested topics for certain content patterns. Because of this, you cannot state the policy this strictly. What you can do is say that each *standalone* topic is its own file. That is, while abstractly we think of a topic as a standalone unit of information, the syntactic constraints that DITA imposes require that you sometimes use nested topics for content that is clearly not standalone. Thus the reality is that there are "standalone" topics and "dependent" topics. Dependent topics should almost never be separate documents while standalone topics should almost always be separate documents as a matter of good data management practice. [But note that there valid exceptions to both rules.] I agree very strongly with Michael that topics should not nest. I originally had the same reaction as others in thinking that sections should be allowed to nest (you can check the mail archives). But upon further reflection I came to realize that everything you want to do with nested sections can be done with nested topics and you avoid the very real danger of putting a whole document in a single topic body. In short, DITA currently says that a topic is really the smallest atomic unit of content organization. Once you accept that, then lots of things become easier. Until you accept this you will likely be very frustrated. Having said all that, I do like the current "nested section" proposal (which should really be renamed to something like "generic containers" or something). There is definitely a need to be able to organize things within a topic body or section as outlined in the proposal. But I also agree that these containers should be clearly understood to not be arbitrarily titled divisions but organizational aids. Cheers, E. -- W. Eliot Kimber Senior Solutions Architect Really Strategies, Inc. "Bringing Strategy, Content, and Technology Together" Main: 610.631.6770 www.reallysi.com www.rsuitecms.com Sent using the Microsoft Entourage 2004 for Mac Test Drive. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
BEGIN:VCARD VERSION:2.1 N:Earley;Jim FN:Jim Earley ORG:Flatirons Solutions TITLE:XML Developer/Consultant TEL;WORK;VOICE:303.542.2156 TEL;CELL;VOICE:303.898.7193 ADR;WORK:;;4747 Table Mesa Rd, Suite 200;Boulder;CO;80305;United States of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:4747 Table Mesa Rd, Suite 200=0D=0ABoulder, CO 80305=0D=0AUnited States of A= merica URL;WORK:http://www.flatironssolutions.com EMAIL;PREF;INTERNET:Jim.Earley@flatironssolutions.com REV:20060614T132755Z END:VCARD
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]