libre status (was RE: XHTML2 I have read it and I like it... GO READ IT!)

[Marc Portier <mp...@outerthought.org>]

> >> How does this affect the libre effort?
> >
> >
> > It redefines it a bit.
> >
> > Here each page has its own navigation links potentially, so IMHO we
> > could decide that a certain page of a directory has its links always
> > present on the left, and the other ones of the pages get added.
> >
> > We gotta discuss this thing, and could maybe decide to not use them
> > (it's a separate module), but anyway they are there if we an them.
>
> OK, well I'll leave that for those who know about Libre then.

In 2 words libre should produce the structure xml (parts of) that is now
skattered over the book.xml-s

since it's program produced, it should be less of a hastle to have it say
something else then change all stuf in the book.xml here and there.  In
other words I don't really give that much about it, somewhere down the line
we'll have to think about the elms and @atts we're going to use to depict
this structure.  My guess now is that this would be something that can be
used as much towards html as to e.g. a toc (towards pdf) in which case it
would probably also be base towards an xml format that aggregates
(cinlcudes) all into a book or something (dreamin' out loud)


Taking the opportunity to give a status update:
- Bit set off by other work ATM, still reading and thinking about libre
though
- dunno when, but will continue that
- the more sideline talks we have about what we like to do, the more I learn
- to my feeling the current scratchpad contrbution is nothing more then a
first prototype

looking at the lack of adoption it surely lacks the out of the box ease of
use it should get
Still hoping thought for others to state opinions on the thing...


Taking it really off topic: (but realted)
What I'ld like to see (out of my league and time-schedule :-(, so here is an
itch I don't think I can scratch myself) is some doc that describes the
"resources" (other then the sitemap: human readable please)
It should be the base for thinking (and discusussing) about more of what we
want to slide into TheContract we offer.
(metrics, junit, jdepends, syntaxhighlights, kinds of navigations, the
tabs???, ...)

It could be a basis for deviding work as well...

If we're doing this meta-web thing (forrest) the full cocoon way, carefull
thought about the URI space we manage should be our prime concern?


regards,
-marc=

RE: libre status (was RE: XHTML2 I have read it and I like it... GO READ IT!)

[Marc Portier <mp...@outerthought.org>]

> > Taking it really off topic: (but realted)
> > What I'ld like to see (out of my league and time-schedule :-(,
> so here is an
> > itch I don't think I can scratch myself) is some doc that describes the
> > "resources" (other then the sitemap: human readable please)
> > It should be the base for thinking (and discusussing) about
> more of what we
> > want to slide into TheContract we offer.
> > (metrics, junit, jdepends, syntaxhighlights, kinds of navigations, the
> > tabs???, ...)
> >
> > It could be a basis for deviding work as well...
> >
> > If we're doing this meta-web thing (forrest) the full cocoon
> way, carefull
> > thought about the URI space we manage should be our prime concern?
>
> Yes, this is the question I wanna ask you all...
>
> Currently, we have our sources in src/documentation.
> Then we copy them to a place where they are built.
> As already said, other tool place their docs somewhere too, in the right
> format, and Forrest should be able to pick them up.
>

to help thinking: such other tools could be the cents now in centipede:
jdepend, junit test results, a locally ran kind of gump, the syntax
highlighter, the umljavadoclet, ...  stuff that can't be ran in a generator
(let allone that you wouldn't want to do it)


there is a number of roles in the play
1. us forresters: we can fix all dirs and sitemap, decide which content
portions are required/optional...
   I'ld like to see us do this in terms of xlayout references in stead of
fixed dirs, that would allow other ant tasks to fit in more nicely.
Drawback is that sitemap will not pick up the xlayout stuff (same problem
with the @skin@ maybe an xslt producing the sitemap is an option? )

2. project builders: actually my feeling is they should just do that: write
up all inside the ./src and nothing more

3. site publisher: the one that decides which portions of content should be
created and published, how they hook up into a navigation --> this means
editing book.xml's (or less libre configs in future) as well as editing
build.xml (??? doesn't sound right, should be more properties.xml work if
you ask me)

4. another site publisher (same cvs co published to different sites, other
skins, same relative URI spaces though): editing/overriding similar
properties in some sort of bot conf


> The problem is: where?
I would go for defined xlayout names that people can change to their need by
editing layout.xml
 and make sure we have some mechanism for generating a sitemap that knows
about these 'changes/customizations'


As I mentioned to Nicola in private earlier I believe that this layout.xml
could help around in the bot as well.
Point is that if we'll going to gump-like build more stuff in one sweap
(forrest at the end of a list of cents that have generated their stuff) we
need to have a build-file flavor that allows to actually make the produced
targets available

Point is build files only make their target-names public, meaning you can
call them, and they produce whatever target you ask them (and you chain up
dependencies) but you can't get TO the target (the side effect is there, the
return type is void if you like.  Build files make something, they don't
'return' something.  While this is great hiding of the implementation it
makes it very hard for various more indpendent processes (cents) to actually
find and use what the other one just build.


> Which URIs are used?
I would let this lead the discussion. rest should follow...
maybe we can list what we have/want and drop in suggested URI-names?

list of haves is:
- dtdx
- xdocs
- faq
- status page (todo)
- changes


up to the wants?
- syntax highlight source code
- maillist archive
- javadoc with uml via xdoc
- books of assembled file snips
- ...


I know Steven started off an ambitious idea on having content aware
pipelines on cocoon-dev, which will surely produce some usefull stuf, but
that doesn't mean we should be (in the mean time) throwing all types of
files just in a big heap and then just see what happens, right?

To organize this out, we have plenty of flexibility in 3 places:
1. defining the url to get it (*.dtdx.html is a good example, the faq could
use the same no?)
2. the navigation (book.xml and overly promised successor)
3. organize/decide where to store it on disk
there is mappings available between them, so we get the nice SoC everyone
likes?

(the content-aware pipelines would make the choice of DTD for a document a
4th flexibility parameter)

(come to think of it, this sounds as enough flexibility so we pretty much
should be able to start off without user definable xlayout dirs if you ask
me, it's just that they are in cvs and more thight to the project using
centipede then to using forrest, meaning people will consider changing it
based on centiped use, and drwan back by forrest possibly not letting them?)

Nicola, I guess centipede would suggest its users to change their layout.xml
at will, right?




> How do we link (also with libre...)
> :-?
Should follow from the full request namespace.

The top down linking with book or libre should be fairly ok I guess, the
cross refs between te docs are the ones that come under the realm of actual
editors... and that's a bit more nasty... starting to think about something
like layout.xml again, and references that can be looked up there?


-marc=
PS: Have been looking at how some of my messages end up on the list...
    As a big sorry for all the typos in past and future mails, I should let
you know I have a great mentor in this:
http://www.brainyquote.com/quotes/quotes/a/q138608.html and
http://home.freeuk.com/elloughton13/aamilne.htm for more

Re: libre status (was RE: XHTML2 I have read it and I like it... GO READ IT!)

[Nicola Ken Barozzi <ni...@apache.org>]

Marc Portier wrote:
>>>>How does this affect the libre effort?
>>>
>>>
>>>It redefines it a bit.
>>>
>>>Here each page has its own navigation links potentially, so IMHO we
>>>could decide that a certain page of a directory has its links always
>>>present on the left, and the other ones of the pages get added.
>>>
>>>We gotta discuss this thing, and could maybe decide to not use them
>>>(it's a separate module), but anyway they are there if we an them.
>>
>>OK, well I'll leave that for those who know about Libre then.
> 
> In 2 words libre should produce the structure xml (parts of) that is now
> skattered over the book.xml-s
> 
> since it's program produced, it should be less of a hastle to have it say
> something else then change all stuf in the book.xml here and there.  In
> other words I don't really give that much about it, somewhere down the line
> we'll have to think about the elms and @atts we're going to use to depict
> this structure.  My guess now is that this would be something that can be
> used as much towards html as to e.g. a toc (towards pdf) in which case it
> would probably also be base towards an xml format that aggregates
> (cinlcudes) all into a book or something (dreamin' out loud)

Yes :-D

> Taking the opportunity to give a status update:
> - Bit set off by other work ATM, still reading and thinking about libre
> though
> - dunno when, but will continue that
> - the more sideline talks we have about what we like to do, the more I learn
> - to my feeling the current scratchpad contrbution is nothing more then a
> first prototype
> 
> looking at the lack of adoption it surely lacks the out of the box ease of
> use it should get
> Still hoping thought for others to state opinions on the thing...

Yes, the main thing is that it's not so easy to understand-use.



> Taking it really off topic: (but realted)
> What I'ld like to see (out of my league and time-schedule :-(, so here is an
> itch I don't think I can scratch myself) is some doc that describes the
> "resources" (other then the sitemap: human readable please)
> It should be the base for thinking (and discusussing) about more of what we
> want to slide into TheContract we offer.
> (metrics, junit, jdepends, syntaxhighlights, kinds of navigations, the
> tabs???, ...)
> 
> It could be a basis for deviding work as well...
> 
> If we're doing this meta-web thing (forrest) the full cocoon way, carefull
> thought about the URI space we manage should be our prime concern?

Yes, this is the question I wanna ask you all...

Currently, we have our sources in src/documentation.
Then we copy them to a place where they are built.
As already said, other tool place their docs somewhere too, in the right 
format, and Forrest should be able to pick them up.

The problem is: where?
Which URIs are used?
How do we link (also with libre...)
:-?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------