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.

But you continue to refer to HTML as such, and not h.t.m.l, and PDF as such instead of p.d.f. Can we try to be consistent? For readers (including myself) who is trying to grasp the broad number of projects that people are creating and using to work with PG texts, it makes it difficult when doing research on "ZML" brings up a completely unrelated series of projects. Similarly, searching for "z.m.l." in this case, doesn't surface anything relevant.

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?

And I'm saying DON'T maintain an XML file. Maintain the text, in a structured, normalized format (i.e. add some parameters by which paragraphs can be spaced, quotes can be used, etc., ala LaTeX).

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.)

XML is infinitely extensible (hence the 'X' in the acronym). This means two completely independent authors can use their own XML formatting and rules, and yet both can output completely compatible formats from their own transformations. That is the whole point of XML. XML is nothing more than a container, an empty bucket. XML does absolutely nothing on its own.

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...

From what I read in recent posts, others are wondering the same about your tool, and what it purports to produce. If you have it in beta test already, why not submit what kinds of files IT can produce, and let others compare that output to their own versions of what their own tools can produce. The point is, turf-wars, name-calling, and vaporware projects aren't adding value to the overall goals of PG, as I read them. That includes my tools as well, but mine aren't really along the same sort of strategic direction as PG's overall goals. They just happen to intersect at several places. David A. Desrosiers desrod@gnu-designs.com http://gnu-designs.com