new LenyaMetaDataGenerator and new namespace?

Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>> * does anyone have objections or suggestions
regarding the
>> implementation? (whitespace will be fixed)
> 
> Some questions:
> 
> - Some methods are rather long with inline comments.
Would it make
>   sense to refactor them into smaller methods with
Javadocs?

sure. i'll try to do that. re javadoc: should
implementation details be
documented as javadoc? or only information that is relevant
for the API?

> - The REALLY_HACKISH_SEPARATOR stuff looks a bit
strange - is this
>   necessary?

of course not. it's there to warn people that it's a
really hackish
separator. ;)

i was looking for a regex function to do the job, and all i
could think
of was the replaceAll/split combination, so i needed a
string that's
guaranteed not to show up in workflowVersion, which is hard,
since the
data format is a) buggy (missing record separator), b) not
really
documented anywhere and c) obviously meant to be extensible
in the
future (var:...).

is there a char that could safely be used? or better yet, a
way to split
the string in one step? i'm not really familiar with the
java api, much
less the regex implementation.

>> * in the light of another recent discussion about
lenya namespaces, what
>> do you think about creating a new namespace for the
output of the
>> metadata generator, so as not to abuse the
page-envelope ns? a
>> suggestion is attached below, please comment.
> 
> Actually I don't think that we need a special meta
data namespace.
> The actual meta data should have their own namespaces
(see my proposals
> about configurable meta data), and the surrounding
elements could
> use a general Lenya namespace.

fine with me. so we create a new flat namespace (no
wrappers), right? if
we get rid of the wrapper elements, does my suggestion come
close to
what you're thinking of?

what "general" lenya namespace do you have in
mind?

>> * since we're not exactly in code freeze, does it
make sense to maintain
>> this generator as a subclass of thorsten's
implementation, or should we
>> rather merge the two? i would prefer the latter.
> 
> If there are no negative implications, I'm in favor of
a single class.
> The less code there is to maintain, the better.

ok, i'll try to send a patch against thorsten's code.
thorsten, is that
fine with you?

>> btw, i'd like to suggest that in the future we try
to create a working
>> relaxng (or xml schema) for any and all new
namespaces that are being
>> introduced, and only then start coding. there is no
better way for
>> normative documentation imho. it would also be nice
to come up with
>> validation schemas for the namespaces that are
already in use....
> 
> Sounds good - but I fear
>  that the schemas won't be maintained
> if they are not applied automatically ...

is it so hard to first discuss and change the grammar before
changing
the code? i don't think this would slow down development...


-- 
"Án nýrra verka, án nútimans, hættir fortíðin
að vekja áhuga."
"Without new works, without the present the past will
cease to be of
interest."
        - Ásmundur Sveinsson (1893-1982)

--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-adminuni-due.de, Telefon: 0203/379-2736


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

El lun, 12-06-2006 a las 10:58 +0200, Joern Nettingsmeier
escribió:
> Andreas Hartmann wrote:
> > Jörn Nettingsmeier wrote:
> >> * does anyone have objections or suggestions
regarding the
> >> implementation? (whitespace will be fixed)
> > 
> > Some questions:
> > 
> > - Some methods are rather long with inline
comments. Would it make
> >   sense to refactor them into smaller methods with
Javadocs?
> 
> sure. i'll try to do that. re javadoc: should
implementation details be
> documented as javadoc? or only information that is
relevant for the API?
> 
> > - The REALLY_HACKISH_SEPARATOR stuff looks a bit
strange - is this
> >   necessary?
> 
> of course not. it's there to warn people that it's a
really hackish
> separator. ;)
> 
> i was looking for a regex function to do the job, and
all i could think
> of was the replaceAll/split combination, so i needed a
string that's
> guaranteed not to show up in workflowVersion, which is
hard, since the
> data format is a) buggy (missing record separator), b)
not really
> documented anywhere and c) obviously meant to be
extensible in the
> future (var:...).
> 
> is there a char that could safely be used? or better
yet, a way to split
> the string in one step? i'm not really familiar with
the java api, much
> less the regex implementation.
> 
> >> * in the light of another recent discussion
about lenya namespaces, what
> >> do you think about creating a new namespace
for the output of the
> >> metadata generator, so as not to abuse the
page-envelope ns? a
> >> suggestion is attached below, please comment.
> > 
> > Actually I don't think that we need a special
meta data namespace.
> > The actual meta data should have their own
namespaces (see my proposals
> > about configurable meta data), and the surrounding
elements could
> > use a general Lenya namespace.
> 
> fine with me. so we create a new flat namespace (no
wrappers), right? if
> we get rid of the wrapper elements, does my suggestion
come close to
> what you're thinking of?
> 
> what "general" lenya namespace do you have
in mind?
> 
> >> * since we're not exactly in code freeze,
does it make sense to maintain
> >> this generator as a subclass of thorsten's
implementation, or should we
> >> rather merge the two? i would prefer the
latter.
> > 
> > If there are no negative implications, I'm in
favor of a single class.
> > The less code there is to maintain, the better.
> 
> ok, i'll try to send a patch against thorsten's code.
thorsten, is that
> fine with you?


Hmm, please, the code in lenya is lenya code. I happen to
have written
the starting code but that is based on other work of this
community. In
Apache there is no code ownership.

Anyway I am always very fine if someone attaches patches to
the issue
tracker. ;) 

Please go ahead and remember there is no such thing like
thorsten's or
andrea's or michi's or ...'s code. If it is in Lenya it
is Apache Lenya
code.

salu2 
> 
> >> btw, i'd like to suggest that in the future
we try to create a working
> >> relaxng (or xml schema) for any and all new
namespaces that are being
> >> introduced, and only then start coding. there
is no better way for
> >> normative documentation imho. it would also be
nice to come up with
> >> validation schemas for the namespaces that are
already in use....
> > 
> > Sounds good - but I fear
> >  that the schemas won't be maintained
> > if they are not applied automatically ...
> 
> is it so hard to first discuss and change the grammar
before changing
> the code? i don't think this would slow down
development...
> 
> 
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


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

Thorsten Scherler wrote:
>> ok, i'll try to send a patch against thorsten's
code. thorsten, is that
>> fine with you?
>
> Please go ahead and remember there is no such thing
like thorsten's or
> andrea's or michi's or ...'s code. If it is in Lenya
it is Apache Lenya
> code.

sure. but if someone has made a contribution, i assume s/he
has special
interest in the code and does maintenance and coordination.

i've seen the other extreme in other projects, a
"fire and forget"
attitude towards code commits, and that's generally not
helpful, so i'd
rather hear  "oh, wait, that's the area i'm working
on, mind if i review
your patch first".



-- 
"Án nýrra verka, án nútimans, hættir fortíðin
að vekja áhuga."
"Without new works, without the present the past will
cease to be of
interest."
        - Ásmundur Sveinsson (1893-1982)

--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-adminuni-due.de, Telefon: 0203/379-2736


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

El mié, 14-06-2006 a las 13:08 +0200, Joern Nettingsmeier
escribió:
> Thorsten Scherler wrote:
> >> ok, i'll try to send a patch against
thorsten's code. thorsten, is that
> >> fine with you?
> >
> > Please go ahead and remember there is no such
thing like thorsten's or
> > andrea's or michi's or ...'s code. If it is in
Lenya it is Apache Lenya
> > code.
> 
> sure. but if someone has made a contribution, i assume
s/he has special
> interest in the code and does maintenance and
coordination.

One feels generally speaking more responsible for the code
but one has
not a special veto nor leadership or obligations. 

> 
> i've seen the other extreme in other projects, a
"fire and forget"
> attitude towards code commits, and that's generally
not helpful, so i'd
> rather hear  "oh, wait, that's the area i'm
working on, mind if i review
> your patch first".

All PMC member should review patches and commits. I
personally do not
have time ATM (less with the world cup) but I will try to
take some of
your patches, apply, review and commit them. 

Like said all PMC member and committer should do this. 

You are right if I would work ATM on this component it is
helping that
we coordinate our efforts. Thanks for all the time and
feedback you
invest in Lenya.

We are very grateful for your contributions.

salu2
-- 
Thorsten Scherler
COO Spain
Wyona Inc.  -  Open Source Content Management  -  Apache
Lenya
http://www.wyona.com     
             http://lenya.apache.org
thorsten.scherlerwyona.com                thorstenapache.org


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