how about removing publication.xml?

hi everyone!


does anyone use the publication.xml files for anything
interesting?
if not, would you object to removing the mechanism
altogether and move 
all important information from there into publication.xconf

benefits:

* gets rid of a number of pipelines in the global sitemaps
* gathers all publication metadata into publication.xconf,
where it 
belongs imho.
* gets rid of a number of important-looking but undocumented
and 
apparently non-functional fields (lenya-revision,
lenya-version, 
cocoon-version) and the bogus <module/> list that
looks like it's 
important somehow and does nothing more than display a
<ul/>.
* provides a generic welcome page with standardized
information and the 
same reader/editor links for everybody.

i guess people will generally be hiding this page from the
public anyways...

lazy consensus in effect ;)


regards,

jörn




------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Michael Wechner wrote:
> Joern Nettingsmeier wrote:
>> Michael Wechner wrote:
>>> Jörn Nettingsmeier wrote:
>> agreed. but imnsho it does not warrant a special
mechanism comprised 
>> of 2 stylesheets, an undocumented ad-hoc xml
namespace and number of 
>> pipelines in the global sitemap. the version
information will be moved 
>> to publication.xconf.
> 
> check the archives and you will see that we actually
agreed to such a 
> merge quite some time ago 

good to know. must've missed that one.

>> right. my current approach provides a generic
listing of the 
>> publication's configuration plus the usual links to
docs and login - 
>> i.e. stuff that is of interest to admins and
editors.
>>
>>> +1 to merge, but merge the whole structure.
>>
>> the whole structure cannot be merged iiuc.
publication.xconf is a 
>> Configurable data file, and the Configurable
interface supports only a 
>> subset of XML - notably, mixed content is not
supported, which would 
>> be natural for a "readme" section.
>>
>> therefore my current approach is to allow only
simple fields in 
>> publication.xconf.
>>
>> i'm also thinking of providing a global
"readme.xml" that is called 
>> via fallback. it can be used by developers to
inform users about 
>> important changes and required tweaks, and
publications could override 
>> it to add their own information.
> 
> I don't think that makes sense. This is what namespaces
are good for.

??? i don't understand. can you clarify?

> Btw, you might also want to consider RDF for this.

look, can we agree that lenya has this little problem of 
over-engineering on one side vs. a minuscule developer
community and 
very little real-life testing on the other side?
i think RDF of all things is not going to change that for
the better.

adding huge stacks of complicated mechanism for absolutely
non-essential 
features is imho part of the reason why lenya is a bit on
the messy side 
today.

>>>> lazy consensus in effect ;)
>>>
>>> based on what definition? I mean about many
days are we talking? What 
>>> about weekend, business days, people on
vacation?
>>>
>>> I think it's important to get this straight,
otherwise it's just 
>>> meaningless
>>
>>
>> note the smiley. i was grinning because i
anticipated the usual 
>> situation: /me starts hacking frantically, and
everybody else is out 
>> of office until monday...
>> it is not my intention to sneak something in
without proper review and 
>> discussion.
>> i'll post a patch for you to review before anything
will be committed.
>> at the moment, the patch is at 557 lines out, 258
lines in, with a 
>> slight gain in functionality (which is how i like
things to be ;)
> 
> I do not consider "lazy consensus" as
something which we should toy 
> with, but a clear definition for a process. As said I
am not sure if we 
> actually defined it clearly. Any pointers are very
welcome.

point taken. i took it to mean "if someone objects,
please speak up." i 
think it's ok to use the phrase for changes that the poster
does not 
think are subject to much debate. if it turns out there is
disagreement, 
commits can always be reverted.



------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Jörn Nettingsmeier wrote:

> hi everyone!
>
>
> does anyone use the publication.xml files for anything
interesting?
> if not, would you object to removing the mechanism
altogether and move 
> all important information from there into
publication.xconf
>
> benefits:
>
> * gets rid of a number of pipelines in the global
sitemaps
> * gathers all publication metadata into
publication.xconf, where it 
> belongs imho.
> * gets rid of a number of important-looking but
undocumented and 
> apparently non-functional fields (lenya-revision,
lenya-version, 
> cocoon-version) and the bogus <module/> list that
looks like it's 
> important somehow and does nothing more than display a
<ul/>.


If you use Lenya in production, then this info makes
perfectly sense

> * provides a generic welcome page with standardized
information and 
> the same reader/editor links for everybody.
>
> i guess people will generally be hiding this page from
the public 
> anyways...


yes, from the public, but not for administrators, etc.

+1 to merge, but merge the whole structure.

>
> lazy consensus in effect ;)


based on what definition? I mean about many days are we
talking? What 
about weekend, business days, people on vacation?

I think it's important to get this straight, otherwise it's
just meaningless

Michi

>
>
> regards,
>
> jörn
>
>
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
> For additional commands, e-mail: dev-helplenya.apache.org
>
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
michael.wechnerwyona.com                        michiapache.org
+41 44 272 91 61


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Joern Nettingsmeier wrote:

> Michael Wechner wrote:
>
>> Jörn Nettingsmeier wrote:
>>
>>> hi everyone!
>>>
>>>
>>> does anyone use the publication.xml files for
anything interesting?
>>> if not, would you object to removing the
mechanism altogether and 
>>> move all important information from there into
publication.xconf
>>>
>>> benefits:
>>>
>>> * gets rid of a number of pipelines in the
global sitemaps
>>> * gathers all publication metadata into
publication.xconf, where it 
>>> belongs imho.
>>> * gets rid of a number of important-looking but
undocumented and 
>>> apparently non-functional fields
(lenya-revision, lenya-version, 
>>> cocoon-version) and the bogus <module/>
list that looks like it's 
>>> important somehow and does nothing more than
display a <ul/>.
>>
>>
>> If you use Lenya in production, then this info
makes perfectly sense
>
>
> agreed. but imnsho it does not warrant a special
mechanism comprised 
> of 2 stylesheets, an undocumented ad-hoc xml namespace
and number of 
> pipelines in the global sitemap. the version
information will be moved 
> to publication.xconf.


check the archives and you will see that we actually agreed
to such a 
merge quite some time ago 

>
>>> * provides a generic welcome page with
standardized information and 
>>> the same reader/editor links for everybody.
>>>
>>> i guess people will generally be hiding this
page from the public 
>>> anyways...
>>
>>
>> yes, from the public, but not for administrators,
etc.
>
>
> right. my current approach provides a generic listing
of the 
> publication's configuration plus the usual links to
docs and login - 
> i.e. stuff that is of interest to admins and editors.
>
>> +1 to merge, but merge the whole structure.
>
>
> the whole structure cannot be merged iiuc.
publication.xconf is a 
> Configurable data file, and the Configurable interface
supports only a 
> subset of XML - notably, mixed content is not
supported, which would 
> be natural for a "readme" section.
>
> therefore my current approach is to allow only simple
fields in 
> publication.xconf.
>
> i'm also thinking of providing a global
"readme.xml" that is called 
> via fallback. it can be used by developers to inform
users about 
> important changes and required tweaks, and publications
could override 
> it to add their own information.


I don't think that makes sense. This is what namespaces are
good for.
Btw, you might also want to consider RDF for this.

>
>>> lazy consensus in effect ;)
>>
>>
>> based on what definition? I mean about many days
are we talking? What 
>> about weekend, business days, people on vacation?
>>
>> I think it's important to get this straight,
otherwise it's just 
>> meaningless
>
>
> note the smiley. i was grinning because i anticipated
the usual 
> situation: /me starts hacking frantically, and
everybody else is out 
> of office until monday...
> it is not my intention to sneak something in without
proper review and 
> discussion.
> i'll post a patch for you to review before anything
will be committed.
> at the moment, the patch is at 557 lines out, 258 lines
in, with a 
> slight gain in functionality (which is how i like
things to be ;)

I do not consider "lazy consensus" as something
which we should toy 
with, but a clear definition for a process. As said I am not
sure if we 
actually defined it clearly. Any pointers are very welcome.

Cheers

Michi

>
> regards,
>
> jörn
>
>
>
>
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
> For additional commands, e-mail: dev-helplenya.apache.org
>
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
michael.wechnerwyona.com                        michiapache.org
+41 44 272 91 61


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Michael Wechner wrote:
> Jörn Nettingsmeier wrote:
> 
>> hi everyone!
>>
>>
>> does anyone use the publication.xml files for
anything interesting?
>> if not, would you object to removing the mechanism
altogether and move 
>> all important information from there into
publication.xconf
>>
>> benefits:
>>
>> * gets rid of a number of pipelines in the global
sitemaps
>> * gathers all publication metadata into
publication.xconf, where it 
>> belongs imho.
>> * gets rid of a number of important-looking but
undocumented and 
>> apparently non-functional fields (lenya-revision,
lenya-version, 
>> cocoon-version) and the bogus <module/> list
that looks like it's 
>> important somehow and does nothing more than
display a <ul/>.
> 
> If you use Lenya in production, then this info makes
perfectly sense

agreed. but imnsho it does not warrant a special mechanism
comprised of 
2 stylesheets, an undocumented ad-hoc xml namespace and
number of 
pipelines in the global sitemap. the version information
will be moved 
to publication.xconf.

>> * provides a generic welcome page with standardized
information and 
>> the same reader/editor links for everybody.
>>
>> i guess people will generally be hiding this page
from the public 
>> anyways...
> 
> yes, from the public, but not for administrators, etc.

right. my current approach provides a generic listing of the

publication's configuration plus the usual links to docs and
login - 
i.e. stuff that is of interest to admins and editors.

> +1 to merge, but merge the whole structure.

the whole structure cannot be merged iiuc. publication.xconf
is a 
Configurable data file, and the Configurable interface
supports only a 
subset of XML - notably, mixed content is not supported,
which would be 
natural for a "readme" section.

therefore my current approach is to allow only simple fields
in 
publication.xconf.

i'm also thinking of providing a global
"readme.xml" that is called via 
fallback. it can be used by developers to inform users about
important 
changes and required tweaks, and publications could override
it to add 
their own information.

>> lazy consensus in effect ;)
> 
> based on what definition? I mean about many days are we
talking? What 
> about weekend, business days, people on vacation?
> 
> I think it's important to get this straight, otherwise
it's just 
> meaningless

note the smiley. i was grinning because i anticipated the
usual 
situation: /me starts hacking frantically, and everybody
else is out of 
office until monday...
it is not my intention to sneak something in without proper
review and 
discussion.
i'll post a patch for you to review before anything will be
committed.
at the moment, the patch is at 557 lines out, 258 lines in,
with a 
slight gain in functionality (which is how i like things to
be ;)

regards,

jörn






------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Gregor J. Rothfuss wrote:

> Michael Wechner wrote:
>
>> I do not consider "lazy consensus" as
something which we should toy 
>> with, but a clear definition for a process. As said
I am not sure if 
>> we actually defined it clearly. Any pointers are
very welcome.
>
>
> http
://lenya.apache.org/guidelines.html#decision
>
> if you were familiar with our guidelines it would save
everyone a lot 
> of time


thanks for the pointer.

But it seems to me I am not the only one (including
yourself). For 
instance I cannot find the definition of "lazy
consensus", but only 
"lazy approval" for code changes on trunk code.
Also it seems to me that 
the subject prefix [VOTE] is missing or is lazy approval not
a "vote" 
and if so would the timeframe of one week not apply ...

re the guidelines I would suggest to add a note re devs with
binding 
votes on vacation which told the community to be on
vacation, which I 
think should also get a chance to vote when they are back
from vacation.

Cheers

Michael

>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
> For additional commands, e-mail: dev-helplenya.apache.org
>
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
michael.wechnerwyona.com                        michiapache.org
+41 44 272 91 61


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Joern Nettingsmeier wrote:

> Michael Wechner wrote:
>
>> Joern Nettingsmeier wrote:
>>
>>> Michael Wechner wrote:
>>>
>>>> Jörn Nettingsmeier wrote:
>>>
>>> agreed. but imnsho it does not warrant a
special mechanism comprised 
>>> of 2 stylesheets, an undocumented ad-hoc xml
namespace and number of 
>>> pipelines in the global sitemap. the version
information will be 
>>> moved to publication.xconf.
>>
>>
>> check the archives and you will see that we
actually agreed to such a 
>> merge quite some time ago 
>
>
> good to know. must've missed that one.
>
>>> right. my current approach provides a generic
listing of the 
>>> publication's configuration plus the usual
links to docs and login - 
>>> i.e. stuff that is of interest to admins and
editors.
>>>
>>>> +1 to merge, but merge the whole
structure.
>>>
>>>
>>> the whole structure cannot be merged iiuc.
publication.xconf is a 
>>> Configurable data file, and the Configurable
interface supports only 
>>> a subset of XML - notably, mixed content is not
supported, which 
>>> would be natural for a "readme"
section.
>>>
>>> therefore my current approach is to allow only
simple fields in 
>>> publication.xconf.
>>>
>>> i'm also thinking of providing a global
"readme.xml" that is called 
>>> via fallback. it can be used by developers to
inform users about 
>>> important changes and required tweaks, and
publications could 
>>> override it to add their own information.
>>
>>
>> I don't think that makes sense. This is what
namespaces are good for.
>
>
> ??? i don't understand. can you clarify?


I don't understand why you want to keep this information
separate? Maybe 
you need to give an example resp. what you think how
publication.xconf 
and readme.xml should look like

>
>> Btw, you might also want to consider RDF for this.
>
>
> look, can we agree that lenya has this little problem
of 
> over-engineering on one side vs. a minuscule developer
community and 
> very little real-life testing on the other side?
> i think RDF of all things is not going to change that
for the better.


I wouldn't consider RDF as over-engineering, but just
consider it as a 
suggestion.

>
>
> point taken. i took it to mean "if someone
objects, please speak up." 
> i think it's ok to use the phrase for changes that the
poster does not 
> think are subject to much debate. if it turns out there
is 
> disagreement, commits can always be reverted.


well, it can be very hard to revert changes.

Cheers

Michael

>
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
> For additional commands, e-mail: dev-helplenya.apache.org
>
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
michael.wechnerwyona.com                        michiapache.org
+41 44 272 91 61


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Michael Wechner wrote:
>>>> i'm also thinking of providing a global
"readme.xml" that is called 
>>>> via fallback. it can be used by developers
to inform users about 
>>>> important changes and required tweaks, and
publications could 
>>>> override it to add their own information.
>>>
>>>
>>> I don't think that makes sense. This is what
namespaces are good for.
>>
>>
>> ??? i don't understand. can you clarify?
> 
> 
> I don't understand why you want to keep this
information separate? Maybe 
> you need to give an example resp. what you think how
publication.xconf 
> and readme.xml should look like

the problem is that textual information of the kind that's
usually 
provided in a CHANGES.TXT or README cannot easily be merged
into 
publication.xconf, because we handle it as an avalon
configuration file, 
and iiuc the methods used to parse it are not as powerful as
native SAX 
and do not allow for mixed content. but imho mixed content
is very 
useful for readmes (the current <readme/> section in
publication.xml 
uses mixed content).

moreover, i think it's not a good idea to mix up informal
textual 
description with precisely defined configuration data.

an example is in the branch i created yesterday evening. be
warned: due 
to the problem with aggregate-fallback i mentioned in
another mail, it 
is not yet fully functional.

>>> Btw, you might also want to consider RDF for
this.
>>
>>
>> look, can we agree that lenya has this little
problem of 
>> over-engineering on one side vs. a minuscule
developer community and 
>> very little real-life testing on the other side?
>> i think RDF of all things is not going to change
that for the better.
> 
> I wouldn't consider RDF as over-engineering, but just
consider it as a 
> suggestion.

sorry for the somewhat harsh reply...  i did not mean to
sound 
patronizing, but i have a very sanguine and passionate
opinion about it 

RDF is certainly a nice concept, but the problem is that
unless 
taxonomies are very carefully designed and adhered to, it
can and will 
lead to a frightful mess of ad-hoc definitions that don't
have any 
benefits for interoperability or clarity.
the way people seem to work on lenya, they tend to come up
with little 
fragmented XML formats that cater to a very particular need
or new 
feature, which makes lenya quite hard to learn and somewhat
quirky to 
use. throw in RDF, and you have a world of pain.

>> point taken. i took it to mean "if someone
objects, please speak up." 
>> i think it's ok to use the phrase for changes that
the poster does not 
>> think are subject to much debate. if it turns out
there is 
>> disagreement, commits can always be reverted.
> 
> 
> well, it can be very hard to revert changes.

true, that's why i have created a branch. (i was surprised
how easy that 
is. i just wonder how easy the merge is going to be...)



------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

On Mon, 2007-02-26 at 09:43 +0100, Michael Wechner wrote:
> Gregor J. Rothfuss wrote:
> 
> > Michael Wechner wrote:
> >
> >> I do not consider "lazy consensus"
as something which we should toy 
> >> with, but a clear definition for a process. As
said I am not sure if 
> >> we actually defined it clearly. Any pointers
are very welcome.
> >
> >
> > http
://lenya.apache.org/guidelines.html#decision
> >
> > if you were familiar with our guidelines it would
save everyone a lot 
> > of time
> 
> 
> thanks for the pointer.
> 
...
>  For 
> instance I cannot find the definition of "lazy
consensus", but only 
> "lazy approval" for code changes on trunk
code. 

This is the same.

> Also it seems to me that 
> the subject prefix [VOTE] is missing or is lazy
approval not a "vote" 
> and if so would the timeframe of one week not apply
...

Normally lazy consensus (or lazy approval) is used when
doing proposals.
Using [PROPOSAL] in the subject helps to identify this mails
and IMO
this is a should be.

salu2
-- 
Thorsten Scherler                                
thorsten.at.apache.org
Open Source Java & XML                consulting,
training and solutions


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org