[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: AW: [dita] Groups - DITA Proposed Feature #12021: Nesting sections (12021.html) uploaded
Hi Chris:
As a counterpoint to the same argument you're hearing (and I realize that you're just the messenger): If we included recursive sections, what would stop authors from creating monolithic content with 4, 5, 6 and even 7 levels of nested content (I have seen it go that deep)?
The real issue I perceive from what you're saying is training. Yes, DITA is very different from other XML content standards with respect to the authoring process, and part of that difference is that there is an implicit planning process that defines the content before it is written. It also has a positive stop-gap effect to make authors think about how the content is structured for reusability and real containment.
In my mind, there's also the philisophical component of KISS that is built in: Write as much content as is needed and no more; reuse where it makes sense. All too often, I've seen authors fall into the trap of creating overly complex, deeply nested hierarchies simply because the DTD enables you to do it. It doesn't mean they can't do it now using nested topics, it just means that there's what I like to call a built in "breaker" to make authors think about how they structure their content. And by all means, if it makes sense to have nested topics, do it.
Beyond just the content, there's metadata. Right now, sections inherit the metadata applied to its container topic. All too often (again), I've seen nested structures where there is explicitly unique metadata for that nested section that is different than the container. Most metadata schemas I've seen implemented use a top-down model where a child element inherits from its parent. However, I've also seen groups go through some pretty wild machinations to make exceptions to this rule, particularly when the content is integrated with a CMS. One of the biggest offenders I've repeatedly seen is authors writing "hybrid" types of content where a parent section contains reference or conceptual material and further in, there's a procedure. And because of the content structure, it becomes increasingly hard to disentangle the content. Using a programming slang, the content is like "spaghetti code".
Having said that, the new proposal goes a long way to enable interoperability for hierarchical content structures that couldn't easily be done with specializations in the past without straying from the fundamental principles of DITA.
Cheers,
Jim
================
Jim Earley
XML Architect/Consultant
Flatirons Solutions
4747 Table Mesa Drive
Boulder, CO 80301
jim.earley@flatironssolutions.com
-----Original Message-----
From: SeicoDyne DITA [mailto:dita@seicodyne.ch]
Sent: Friday, November 09, 2007 3:33 PM
To: 'Michael Priestley'
Cc: dita@lists.oasis-open.org; 'Grosso, Paul'
Subject: AW: AW: [dita] Groups - DITA Proposed Feature #12021: Nesting sections (12021.html) uploaded
Hello Michael,
as promised have talked to some people from the machinery industry regarding the nested sections issue. And it seems that most point have been clearified. But may have now the opportunity to better explain why some still insist of reflecting the need of some sort of nexted sections.
This requirement is not connected to the planning of a document but with the way some authors are used to work.
I have to state that many - even in the machinery industry - totaly follow the one section level per topic concept and would never leave that track. Especially people who are addicted to information matting.
The wish of beeing able to split a section in subsections is comming from authors who write documentation in which the degree of complexity is growing while they are writing. It is always the same reason: An author is planning a document, splits it into topics, nests topics as required and starts to work. He/she writes the content of a topic, creates a couple of sections. While writing the sections he/she recognizes, that the structure is too flat and an additional level of hierarchy is needed.
Of course, the author now can restructure the topic and split the sections in separate topics to get the required structure. In theory that is ok and would solve the problem, but practically, the author gets pretty angry as restructuring a topic with a couple of sections into several topics needs far more time than to work how he/she is used to work by just adding a next level into the existing one.
And one point that may drive some crazy is the fact that maybe from 7 sections only one needs a deeper structure. And then to split that single topic in several to get the required nesting seems to be an overkill for some authors.
Hope I was able to reflect what challanges these people.
I fully agree, this is still a question of planning and this requirement should not challange us. But I just try to reflect what I hear from the field.
Best regards
Chris
________________________________
Von: SeicoDyne DITA [mailto:dita@seicodyne.ch]
Gesendet: Dienstag, 30. Oktober 2007 15:43
An: 'Michael Priestley'
Cc: dita@lists.oasis-open.org; 'Grosso, Paul'
Betreff: AW: AW: [dita] Groups - DITA Proposed Feature #12021: Nesting sections (12021.html) uploaded
Yes Michael,
for the pilot they answered that they will go with what is available. So it was no longer the case for them in the pilot.
Nevertheless it will be a case again when they go for the productive part, especially regarding legacy data.
Maybe with new documents they can find a way, but it seems that Novartis can not port existing documents into a standard DITA structure without splitting the content into sensless small crumbs.
Chris
________________________________
Von: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Gesendet: Dienstag, 30. Oktober 2007 15:19
An: SeicoDyne DITA
Cc: dita@lists.oasis-open.org; 'Grosso, Paul'
Betreff: Re: AW: [dita] Groups - DITA Proposed Feature #12021: Nesting sections (12021.html) uploaded
Hi Chris,
When we reviewed this proposal with Novartis, they said it met their needs - is that no longer the case?
In my own experience, there are different reasons for grouping content together at authoring time and at delivery time. You may want topics grouped together in a single document for authoring, and split up for delivery, or vice versa. This is one of the issues addressed by the chunking feature in 1.1.
So if a group decides not to nest topics during authoring, but then wants to nest sections with multiple levels of headings, I have to wonder why they aren't just nesting topics. But I didn't think that was Novartis's problem.
As to whether "topics stand on their own" vs. nesting sections - I think there are always some topics that do not stand on their own - especially overview topics. Yet there are still reasons to sometimes manage them or treat them as topics separately - and sometimes that decision about whether it stands on its own is really one the reuser has to make, not the author.
If the author uses topics for things that have unique titles (ie introduce new subjects), and nests topics when they need complex content, that leaves the door open for reusers to choose topics to reuse, and make their own decision. If the author doesn't use topics, then their content is not addressable or chunkable by others - and the reuse door is closed.
Michael Priestley
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
"SeicoDyne DITA" <dita@seicodyne.ch>
10/30/2007 09:56 AM
To
Michael Priestley/Toronto/IBM@IBMCA, "'Grosso, Paul'" <pgrosso@ptc.com>
cc
<dita@lists.oasis-open.org>
Subject
AW: [dita] Groups - DITA Proposed Feature #12021: Nesting sections (12021.html) uploaded
Yes indeed we had that case last year at Novartis, mainly regarding taking over legacy data.
The main point that Novartis mentioned in that discussion was:
1st they decided that each topic relates to one file in the database,
2nd if they are going to split content of one topic in several topics, most of their content will loose the context. So content that belongs literally together would be split appart into separate files. This splitting would not only make the content highly difficult to manage, those topics would no longer be meaningful when they stand alone.
Novartis has not yet decided if they go for DITA, Docbook or if they develop their own schema.
From my last discussions I heared that they will go for DITA and call it DITA+ by bending or breaking our rules. As already mentioned, how Novartis will proceed is not yet decided, they are waiting to hear what the DITA TC decides.
I would like to ask that question to the specialists of topic based authoring. What has more weight:
- a topic is a unit of information that is meaningfull when it stands alone
- a section in a topic is not alowed to contain sections
Chris Kravogel
SeicoDyne GmbH
Eichenstrasse 16
CH-6015 Reussbühl
Switzerland
Tel: +41 41 534 66 97
Mob: +41 78 790 66 97
Skype: seicodyne
www.seicodyne.com
christian.kravogel@seicodyne.com
Member of the DITA Technical Committee
Chairman of the DITA Machine Industry Subcommittee
________________________________
Von: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Gesendet: Dienstag, 30. Oktober 2007 14:34
An: Grosso, Paul
Cc: dita@lists.oasis-open.org
Betreff: RE: [dita] Groups - DITA Proposed Feature #12021: Nesting sections (12021.html) uploaded
My recollection is that it was primarily for use in creating regular groupings of sections or of content under sections for specialization purposes. This was the use case for Novartis that Chris brought forward, and also the use case from Paul Prescod who co-designed the original proposal.
For example, with these extra levels, you can model something like:
<messagebody>
<problem> (from section)
<userresponse> (from bodydiv)
<analysis> (from section)
<recovery>
...
etc.
There were some more complex use cases modeled in the original note series with Paul Prescod I believe.
I think where people need to model freely titled nested divisions, the answer continues to be nesting topics rather than nesting sections - to try to prevent the bloating of topics into whole chapters or books of content (losing the constraints on topic size/complexity that are among the distinctions between DITA and DocBook). But where additional levels of organization are needed within a topic that do not represent new ideas or topics (and thus do not require new unique headings), I think this proposal gives the specializer considerably more freedom - as well as providing a general mechanism for grouping sections or blocks for the sake of conreffing a mixed range or for simplified conditional processing/metadata.
Michael Priestley
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
"Grosso, Paul" <pgrosso@ptc.com>
10/30/2007 09:12 AM
To
<dita@lists.oasis-open.org>
cc
Subject
RE: [dita] Groups - DITA Proposed Feature #12021: Nesting sections (12021.html) uploaded
I was a little surprised to see this suggesting a bodydiv/sectiondiv
element but still not allowing sections to nest, which is what I
thought was meant by nesting sections.
I thought one of the drivers of this requirement was to be able
to model DocBook's nested sections more easily, but with the
suggested model, this would be even harder.
What are the benefits of this suggested model over simply allowing
section to contain section?
paul
> -----Original Message-----
> From: jim.earley@flatironssolutions.com
> [mailto:jim.earley@flatironssolutions.com]
> Sent: Tuesday, 2007 October 30 7:15
> To: dita@lists.oasis-open.org
> Subject: [dita] Groups - DITA Proposed Feature #12021:
> Nesting sections (12021.html) uploaded
>
> This is the HTML version of proposal 12021
>
> -- Mr. Jim Earley
>
> The document named DITA Proposed Feature #12021: Nesting sections
> (12021.html) has been submitted by Mr. Jim Earley to the OASIS Darwin
> Information Typing Architecture (DITA) TC document repository.
>
> Document Description:
>
>
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/dita/document.php
> ?document_id=25904
>
> Download Document:
> http://www.oasis-open.org/apps/org/workgroup/dita/download.php
> /25904/12021.html
---------------------------------------------------------------------
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]