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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
