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