forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <>
Subject Re: Wish/Dream List for Document DTD
Date Tue, 21 May 2002 09:19:48 GMT
From: "Piroumian Konstantin" <>

> Hi all!
> This is the summary of the discussion between me and Steven on the
> 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>

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


> 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
> 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.

> 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
> allow to have custom styles for elements with 'id' and usage of user
> 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".

> 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
> all the possible needs for real documents.

Not hard. You just need to add new meanings or have a more intelligent

> 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

> 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
> 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?

> 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.

> 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
> 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
> the result format using a parameter
> - use something like <cinclude:include
> src="cocoon:/format/sample.xml/?type=source" />, but this will require
> 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

> 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.


Nicola Ken Barozzi         
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

View raw message