Re: Re: [all] Requirements default publication

Christian Egli wrote:
> Andreas Hartmann <[email protected]> writes:
> 
> 
>>have we already stated the purposes of this publication?
>>a) low entry barrier
>>b) best practise showcase (exploring for us and learning for others)
>>c) show what's possible
>>
>>I guess (b) is the main point, isn't it?
> 
> 
> I think it is mainly b but could possibly be made into a.
 From my point of view, it is (a) and (b) - definitively not (c). (b)
would be the main focus. But if we want to attract more people (users,
contributers) we need a publication they can use with only few
modifications for their own needs ("immediate value after download") -
which would be (a).

> 
> 
>>Document URI space
>>------------------
>>- No predefined URI space
>>- No URI-doctype mapping
>>
>>So we will use sitetree framework + DoctypeMatcher?
> 
> 
> I think we will have to do something along these lines.
Correct

> 
> 
>>Doctypes
>>--------
>>- Two doctypes (as few as possible): simple content doctype and XHTML
>>  doctype
>>
>>I'm still against the XHTML doctype if this shall be a
>>best-practise publication. I agree that this is useful to
>>integrate existing content. But maybe we should point to the
>>drawbacks of this approach?
> 
> 
> Sure we can. It just seems that the XHTML doctype is a very pragmatic
> approach which can simplify things
I am not sure about the XHTML doctype myself. But from my experience,
there will always be a point where the user wants to have a page that
looks different than all the other pages. It could be a main advantage
of Lenya if the user sees that he can add easliy non-standard pages
(without any coding and any help from outside).


> 
> 
>>- No collection doctype (just navigation)
>>
>>What is actually the difference? Do you mean that
>>section overview pages etc. can't be created/web-edited/published
>>etc. but only edited as XML?
> 
> 
> I think the idea is to keep the publication as simple as possible and
> therefor not even have a collection type, i.e. each page is either a
> simple doc or a XHTML doc. That means that there are no section
> overview pages. We could add this but it would complicate the
> publication.
>  
That's what I think. There wouldn't be such a thing as an overview page 
that just displays links to the child pages. If the user wants to add 
links to the child pages in the content area of the page (in addition to 
the navigation) he has to add the links manually in the editor.

> 
>>- Homepage: simple content doctype
>>
>>Here I could even imagine to use the XHTML "doctype". Homepages
>>tend to be stylish and differ very much from the content pages.
>>I wouldn't force the user to use the content doctype for the
>>homepage (it tempts to tweak the doctype, I know this from
>>cocooncenter).
> 
> 
> Of course this is possible. I think again the point is that there is
> no extra doc type for the home page.
Agreed. I just thought that it is more of an effort for the user
to create an XHTML document and to upload it than to just edit the
content with the editor.

> 
> 
>>Simple content doctype
>>----------------------
>>- Editable by Xopus and Bitflux
>>- Elements:
>>- Page Heading
>>- Subtitle
>>- Lead
>>- Paragraph
>>- Section heading
>>- List
>>- List item
>>- Table
>>- Table row
>>- Table cell
>>- Image
>>- Image caption
>>
>>Do we have such a schema? Otherwise - what about the Forrest doctype?
> 
> 
> That was my original question also. Why don't we just take the forrest
> doctype especially as there are people working on simplifying and
> completing it as we speak (see forrest-dev list). But I suppose
> there's an argument for keeping as simple as possible which is the
> list of elements outlined above.
 From my experience with unipublic, I would define our own very simple
xml with meaningful element names. Then the xml and the xslt can be read
and understood very easliy by the beginner who wants to learn how Lenya
works.

> 
> 
>>XHTML doctype
>>-------------
>>- Editable with Xopus?
>>
>>-1. There are enough good HTML editors.
> 
> 
> Ok.
> 
> 
>>Navigation
>>----------
>>- Navigation is built automatically
>>
>>I guess you mean the navigation elements are built
>>from navigation files?
> 
> 
> No, the intent is to add pages to the navigation as they are added to
> the publication. I know this has problems when you start adding
> hundreds of pages but again KISS.
> 
> 
>>- Navigation folding (static)
>>- Highlighting of current location
>>
>>Components
>>----------
>>- Site Tree Manager
> 
> 
> Felix: What do you mean by "Site Tree Manager"?
I was just thinking about a better name than "sitetree framework / 
doctype matcher".
> 
> 
>>- Navigation Framework
>>
>>I would add the search engine.
> 
> 
> If it can be done simply, sure.
> 
Of course.


-Felix