forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Noels" <>
Subject RE: Wish/Dream List for Document DTD
Date Tue, 21 May 2002 10:09:13 GMT
I'm trying to stay focused on my Forrest primer, but here goes anyhow

> From: Nicola Ken Barozzi []
> From: "Piroumian Konstantin" <>
> > Hi all!
> >
> > This is the summary of the discussion between me and Steven on the
> additions
> > to the document format. Ideas were inspired by my rewriting
> of some Cocoon
> > docs into v11 format. So here they are:
> >
> > 1. Special formatting for text.
> Aaaarg. We need semantics!
> > 1.1 Text highlighting element (as it was proposed in the
> > resources/layout/ The name of the
> element is not
> > defined yet (proposed 'hi' was considered not very good).
> Other proposals
> > are welcome. This formatting can be used to catch readers
> attention to
> > particular parts of the text.
> <hili/> <highlight/> <hi>

I'd stick to <highlight/>, too

> > 1.2 Strike out text formatting. Proposal: '<strike>' (as HTML). This
> > can be used to display deprecated class names or so.
> <deprecated/>

<strikeout/> seems a bit more clear to me, but is less semantical :-s

over to you guys, will add both to document-v11.mod when you agreed upon
an elementname and patch document2html accordingly

[process] I know having a thread about element naming seems like
nitpicking, but we should do it this way prior to patching: in the
future, a lot of projects will depend on our DTD's.

> > 1.3 Advanced version of the 1.1: special styling for some elements
> > (table, th, tr, td, p, simple text, etc.). This can be
> achieved by adding
> > 'class' to common attributes (predefined class values can
> have semantical
> > meaning, like: 'deprecated' or 'highlight'). I need it to
> mark some markup
> > elements of i18n transformer as deprecated (there is a table of the
> elements
> > with links to details and it'd be fine to color the rows
> with deprecated
> > elements in a different way and strikeout the names of elements).
> Maybe we can logically group the "inline" elements like <emph>,
> <deprecated>, etc and have the class attribute require one
> from this list.

I'd like to do this after refactoring the stylesheets according the
refactored DTD's - please continue the discussion however.

> > 1.4 Custom styles for particular document. This can be achieved by
> > adding a reference to a CSS file from inside of the
> document. This will
> also
> > allow to have custom styles for elements with 'id' and usage of user
> defined
> > styles. Example.: I want to display a list of supported
> locales using one
> > coloring for locales with the same language, but a
> different country code
> > (en_GB, en_US). I could use <li id="en">US Locale</li> and
> <li id="en">UK
> > locale</li>.
> Then you should abstract the semantical meaning.
> Maybe something like "grouping".

Technically possible, if we tune the sitemap to this - shouldn't be any
problem as long as it's optional. Don't forget you'll perhaps be the
only user of this (and be self-supporting for upgrades and the like).

> > Notice: I realize that this breaks the semantical purpose
> of the DTD, but
> > it's hard to beleive that having only semantical markup is enough to
> satisfy
> > all the possible needs for real documents.
> Not hard. You just need to add new meanings or have a more intelligent
> stylesheet.

Yeah. I'm *not* proud of what I committed to CVS right now - but I hope
it provides a working environment for people jumping in to finish the

> > 2. Links/References
> >
> > 2.1 Links to resources that are not present at the build time break
> > the build. Any good idea on how to solve this? Maybe a
> matcher in sitemap
> > that return nothing or something like: <document>Will be added
> > later</document>>
> Currently link to dirs do not break the build, but only warn.
> I think that this is ok, since it assumes that a dir is
> managed by another
> system.

Fair enough. That'll do for the moment, I guess.

> > 2.2 Jumps between document content. E.g.: in the list of supported
> > markup elements for a transformer it is needed to have jumps to the
> details
> > for that elements. Currently I've used special anchors near
> the section
> > names with the details. Having some automagics here would be fine.
> Yes, we need this.
> Automagic, how?

I already patched document2html offering both @id and generate-id()
based linking for <section> elements - already a step in the good
direction, I guess (for intra-document links). To be committed later
during the day.

> > 2.3 XPointer-ish syntax for referencing other xdocs/content (this
> > one is really an RT, didn't thought how this can be performed).
> My contribution to a RT: links to a topicmap entry, and every
> file contains
> refs to a topic.

XPointer/XLink would be "cool" (tm). Having an XLinkTransformer or the
like would be wonderful. Our long-due book.xml-nuker could possibly
maintain an automagic LinkBase. TopicMaps seem like one step too far to
me currently.

> > 3. Special content/formatting
> >
> > 3.1 It would be fine to provide syntax highlighting for the <source>
> > elements. Say: <source type="xml" /> or <source type="java"
> /> (maybe
> <code>
> > element also can concidered). It obvious, that source is
> better read when
> > it's colored in a reader-friendly manner. Some ideas on
> implementation:
> > - special transformer (like FragmentExtractorTransformer)
> > that will process <source> elements and present them in
> some intermediate
> > XML (that can be trasnformed to HTML using XSLT) or
> immediately transform
> to
> > the result format using a parameter
> > - use something like <cinclude:include
> > src="cocoon:/format/sample.xml/?type=source" />, but this
> will require
> some
> > transformer to pass the actual source text to a the
> formatting pipeline.
> > - no other idea yet: yours are welcome
> I would put the parameter as you suggest, but leave the
> formatting to the
> skin.

There's a number of possibilities, we had some experience with JavaML,
too. I'll come back to that.

> > 4. Form elements.
> >
> > 4.1. E.g.: search and feedback forms, etc. This can be used even now
> > using 'action' attributes in forms referencing external
> dynamic resources
> > (Google, forums, etc.).
> Mail forms.


> > That's all for now. More to come as I move on working on the docs.

AAArgh :-)


View raw message