Bernhard Huber wrote:
>
> Hi,
>
> as noted by david there were some js problems, i removed the js refs
> from the sample pages,
> so a second try trigger some discussion about more accurate reference
> documentation.
>
> I try to summarize what I have done, i make a distro available under
> http://members.a1.net/berni_huber/ref-docs/index.html .
>
> My idea was not to replace javadoc documentation, but to help writing
> the sitemap, avoiding to go to the java source code,
> and to avoid writing too much explicit documentation which is never
> uptodate with the java source code.
I love it.
> That's the whole indention.
>
> Defined cocoon:tags :
> @cocoon:name {name} name is sitemap name of the sitemap componented
> implemented by this class
>
> Proposed cocoon:tags:
> @cocoon:deprecated [yes|no] Used for documenting deprectated sitemap
> components.
Hmmm, will this scale in the future?
What about coming out with a more-or-less standard extention to the
javadoc system and provide namespaces? for example:
/**
* This is my comment.
*
* @namespace:cocoon http://apache.org/cocoon/2.0/
* @cocoon:deprecated no
* @namespace:xsp http://apache.org/xsp/1.0/
* @xsp:deprecated yes
*/
what do you think? might be FS but I think tag collisions will happen
frequently expecially if this system is moved to Ant or something like
that.
> More cocoon:tags:
> @cocoon:optional [yes|no] describing if it is optional
> @cocoon:core [yes|no] describing if its core
If something is not core is optional, or is there something in between?
> @cocoon:input-dtd for transformers describe the expected input
> xml-document-type
> @cocoon:output-dtd for transformers, and generators describe the
> expected xml-document-type produced.
Nah, this doesn't work.
XSLTTransformer: what are the input/output schemas?
XMLSerializers: what is the input schema?
yes, some components know the output or the input (directory markup for
the directory generator, FO for PDFSerializer), but is this worth the
effort? pipelines can't be validated at authoring time anyway.
> @cocoon:objectModel ? describe what is put into the objectmodel map.
Hmmm, I think this is too code-level.
What about things like in-out parameters [for actions, matchers,
selectors], or things like returned tokens... anything that can be
useful for sitemap authoring (probably even to assist an authoring tool)
What do you people want from this?
You'd better speak now :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
