david said:
Can we start using proper acronyms here? The industry accepted term you want to be using here is XML, not "x.m.l.", unless by "x.m.l" you mean some other format which is not XML.
well, i'm not much for "industry accepted terms", but the _real_ reason i put the periods in is that with any acronym, when you use all-lower-case, as i do, using periods helps reader comprehension. i even do it with z.m.l., so it's no slam on x.m.l., ok? if it bothers you, just ignore it. *** i said:
there is also the question of _maintaining_ the x.m.l. file -- entailing things like editing errors out of it, updating it, etc. where do we get volunteers who have the expertise to do that?
david said:
Create a tool that can go from PG etext, in "normalized" format to PG's accepted version of an XML document of that PG work.
i'm not clear what you're saying here. the question is the difficulty of maintaining an x.m.l. file. you would transform the x.m.l. file to do maintenance on it? also, there is no "normalized" format, nor is there an "accepted version" of an x.m.l. document of the corresponding p.g. e-text. (but there are lots of contenders for that position.)
I thought your tool did exactly this. Am I mistaken?
it will. and when it does, i'll submit those files for evaluation. in the meantime, i'm asking karl if he can do it with x.m.l. now. everyone talks about it like it's a developed, stable technology. so i'm wondering what the hold-up is... -bowerbird