forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Noels" <stev...@outerthought.org>
Subject RE: DTD questions
Date Fri, 31 May 2002 12:51:48 GMT
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]

> > J.Pietschmann wrote:

<snip/>

> What about the discussion we had about having only *one* link tag?
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=forrest-de
> v@xml.apache.o
> rg&msgId=339180
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=forrest-de
> v@xml.apache.o
> rg&msgId=339459
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=forrest-de
> v@xml.apache.o
> rg&msgNo=252

+1

<snip/>

> Which brings us back to the naming of the dtds.
> I *really* want to see the current DTD labelled as dev
> somehow, to prevent
> this (at least in part).

I'll see what I can do, you're right about this.

> > I would prefer to see proper XML validation via RELAX NG
> > happening. Then the stylesheets can rely on the XML stream
> > and be less verbose.
>
> http://www.xmlhack.com/read.php?item=1667

-1, I don't see how we can constrain this using DTD's, RELAXNG or
XSchema in a useful way. And people following XML-Dev (Joerg) already
know that while RNG is a Draft ISO spec, one of its authors doesn't mind
admitting publicly that marketing RNG has failed - so I won't assume
lots of tools doing RNG validation. I'm -1 on maintaining 2 grammars
independently of each other - but I know James Clark has an RNG2DTD
converter, need to check that however. But how will we integrate this
within the Cocoon environment? Xerces doesn't do any RNG validation
AFAIK - and validation should be an integral part of the process.

> > I too am not happy with generated anchors - they are always
> > changing, so you cannot link from another document to a specific
> > FAQ. I was pleased to see your recent Topic Map thread, and will
> > try to comment there.

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?

> > > - Many elements have a title attribute, in particular sections,
> > >    including FAQ sections. This precludes using markup in
> titles, in
> > >    particular <code>, <em> and a yet to invent <keyword>
> element (for
> > >    indexing, an obviously interesting feature for FAQs).
> I'd suggest
> > >    deprecating the title attribute and introducing a title child
> > >    element. Whether DocBook is about to be reinvented or not is a
> > >    question I will not ask here.
> >
> > You provide very sound reasons. There was some discussion
> > on forrest-dev around February - i cannot find it quickly.
>
> I find it harder to write stylesheets for the docbook way.
> 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 ;-)

> > > - The FAQ DTD has a part element for structuring the FAQ.
> This sounds
> > >    rather artificial. What's wrong with faqsection?
> >
> > Mmmm .. Not sure happened with that. The Cocoon-1/faq.dtd
> > had faqsection. Then Cocoon-2/faq.dtd dropped it (perhaps
> > accidently). Then Forrest/faq.dtd brings it back differently.

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.

> > > <plug>
> > >   With namespaces and XSchema, FAQ specific elements
> could have their
> own
> > >   namespace. This allows faq:section elements.
> > > </plug>
> > >
> > > - There is still a template for the connect element.
> >
> > Is the <connect> element still relevant? There is still
> > confusion over the purpose of link|jump|connect and differences
> > between DTD v10 and v11 in this area. Does anyone know what
> > the <connect> is/was used for? Is it safe to drop it in DTD v11?
>
> 1 link tag... pleeeease ;-)

Let's vote on this.

> > I did a UNIX find/grep through Cocoon and Forrest xdocs and it
> > is not used anywhere. (There was one unlinked C2 doc at
> > xdocs/css/testdoc.xml that looks useful. It too has a message
> > "FIXME: what is this 'connect' thing for".)
>
> wireless? ;-P

LOL.

> > > <plug>
> > >   With XSchema, an XSLT based tool could perform some
> primitive checks
> > >   on the style sheet, it could warn if templates matching removed
> elements
> > >   are still there.
> > > </plug>
> >
> > Great idea. That would help with stylesheet maintenance.
>
> +10

That would be cool, indeed.

> > > - I'd also suggest to add a catch-all template to document2html in
> > >    order to avoid nasty surprises caused by unhandled elements:
> > >
> > >     <xsl:template match="*" priority="-2">
> > >     <xsl:if test="$check-all">
> > >       <xsl:message terminate="yes">Unexpected
> element</xsl:message>
> > >     </xsl:if>
> > >     <xsl:apply-templates/>
> > >   </xsl:template>
> >
> > OK. I will add that in over the weekend.
>
> +1

-1 - this should be solved/degraded gracefully, and not breaking the
build!

> Have it output also any useful info to where the tag is, and
> what it is.
>
> > If you have patches for anything else then please send them
> > via forrest-dev list.

> > > - The document DTD has some hooks for augmenting certain element
> > >    content. In the FAQ DTD the faq.mod is included after the
> > >    document.mod.  This makes it impossible to use the
> hooks from within
> > >    the faq.mod.  Is it planned to use the hooks for
> something, and if
> > >    so, what are the guidelines for this? Should there be
> a separate
> > >    faq.local.mod for local definitions, or should the
> faq.mod use for
> > >    this?
> >
> > I am a bit lost on that - perhaps someone else can answer.
>
> Ahem... anyone else? ;-)

I know, and Joerg has a point. The remodularization was a quick hack by
me. Doing this local stuff however will be hard to reflect in the
stylesheets, too. We need the modular structure, I'm not sure whether we
need all this local definition placeholders.

</Steven>


Mime
View raw message