Marcus Crafter wrote:

On Wed, 2004-07-28 at 14:15, Carsten Ziegeler wrote:

But let not implementation details (or technics) drive the syntax.
It is more important to have a good sitemap language than to have a clean and small implementation.


I agree too mate.

Something that I'm wondering about is what the relationship would be
between flowscript and sitemap-script if we allowed the sitemap to be
scriptable.


as it is today: a function-call

what else could we call <map:call function="..." /> ?

My first impression would be that the 2 would merge - the temptation
would be there for our users to write their flowscript around their
sitemap definition (good thing or bad thing?)


the engineer's answer: it depends (as from a famous dilbert cartoon)

or the perl vision: make simple things simple and hard things possible

So if you choose to inline your function-call then in our current view we would see that as blasphemy, but for application X it might just be the correct thing to do.

The XML syntax prevents keeps flow and sitemaps separate - perhaps its
worth working out the relationship between both concepts?


Very true, but subject to the existential question:

(paraphrazing Stefano in [1])
Is there a real (universally applicable) separation here?

If there is a need to separate (in your situation): you apply it by modularizing this new 'site-script' in modules and functions. If it is not, then who are we to impose any way of working?

Rest assured I'm equally concerned with a number of other voices here about (using Ugo's wording) 'giving just more rope to hang yourself in'
However, when I see people 'removing and merging' then I can only see less rope :-)


IMHO we need to be honest/modest about how far any cocoon-user actually wants to be 'guided' and 'helped'. One of the main explanations I've seen in the proclaimed 'tuff learning curve surrounding cocoon' is the 'atomicity' of it's set of features: catch all or none of it, and thus truggle through quite a long period of frutration getting there...


Purely from a didactical POV I would love to be able to
- make a shortcut now and get this lesson over with
- rehash, modularize and add complexity in the next lesson
- and replace one lesson to learn that extra syntax by having more time for exercises


I honestly think Ugo is on the right track with his drive for 'simpler'

-marc=
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109103885629692&w=2
--
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]                              [EMAIL PROTECTED]

Reply via email to