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: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
