forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diana Shannon <terrac...@mac.com>
Subject Re: DTD questions
Date Sun, 02 Jun 2002 00:55:28 GMT

On Friday, May 31, 2002, at 05:56  PM, J.Pietschmann wrote:

> From: "J.Pietschmann" <j3322ptm@yahoo.de>
> Date: Fri May 31, 2002  05:56:41  PM US/Eastern
> To: forrest-dev@xml.apache.org
> Subject: Re: DTD questions
> Reply-To: forrest-dev@xml.apache.org
>
> "Steven Noels" <stevenn@outerthought.org> wrote:
> > > > [generated anchors]
> > I don't like the Topic Maps approach - this is simply too much work 
> for
> > people adopting Forrest for their project needs. I'm -1 on the 
> generated
> > anchors, too, but what else can we do? We can't force specify people 
> to
> > add an ID attribute on each section, just for creating a little TOC on
> > top of the generated document. We could use numbers instead of ID's
> > however, or the text of the section title.
> >
> > Opinions?
>
> Topic maps, explicitely specified anchors and generated anchors can
> and likely will coexist.
>
> Generated anchors mean the links *have* to be generated too. This is
> fine for generating TOCs and index pages.
>
> Explicitely specified ids are targets for manually inserted
> links. Whether the links are directly placed into the xdocs or placed
> in a topic map is of no concern for the id.
>
> The topic map is used as a central repository for links which are used
> often, and perhaps from different documents. In case the URL changes,
> there is only one change instead of a global S&R. It does not prohibit
> placing links directly into the xdocs (although I find hrefs to .html
> a bit strange in xml files). Links can be migrated to and out of the
> topic map at any time, perhaps supported by a tool.
>
> Really easy in Cocoon: directory generator -> xslt pulling in all
> xdocs via document and extract <link> -> xslt for sort+count hrefs ->
> html formatter -> happy developer staring at a nice report -> check
> boxes next to hrefs to migrate to the topic map -> action: stream edit
> documents and topic map using xslt.
>
> > > > > [title]
> > > I also don't see the need for using markup in titles;
> > > personally I've never
> > > seen it used AFAIR.
> >
> > Glad I finally found a partisan on this ;-)
>
> If the title is an attribute, you'll never see markup there for
> obvious reasons.
>
> Although I don't want to start a flame war about attribute
> vs. element, there is still the rule of thumb: if it's finally seen on
> the screen/paper, it should be put in an element.

Please make it an element. What the simple need, conservatively applied, 
to include <br /> for
some titles?

> > My fault, I never knew about the faqsection - would you like this to 
> be
> > brought back to live? I like part better, but that's personal.
>
> Part is both generic and overloaded, and not generally associated with
> either a FAQ nor with a document structure element at the same level
> of a section (I'd associate it either with a logical structure above
> chapter or physical structure above page, perhaps a set of "volumes".
> Well there are novels using a logical structure of work->book->part
> ->chapter->section->... rather humongous novels of course)
> Of course, faq:section would be even better than faqsection :-)

I'm trying to organize Cocoon FAQs into sections, and it's next to 
impossible. Many Cocoon FAQs clearly belong in multiple sections. 
Perhaps that's somewhat unique to Cocoon being a glue technology. 
Instead of sections (although it's ok for now), I think it's better to 
have something like a topic map decide relevant FAQs for a given 
category/topic.

What I think we *do* need, for lots of document content types, is some 
way of indicating the source code/components and even version upon which 
they depend. Then, when something about that code/component changes, 
such content (FAQs, tutorials, how-tos, etc.) can be found and edited 
easily. When those inevitable delays occur, such docs could at least 
display warnings about being out-of-date/alpha etc. XSLT could include 
such flags (comparing doc version to release version) until the content 
is updated to reflect the current software status.

Have you seen this anywhere?

Diana


Mime
View raw message