
FWIW, contrary to what BB is implying, I do not consider myself "one of the XHTML crowd." I have pointed out prior, that when I go looking for XHTML or XML tools I also find that they are sorely lacking. What there are "a lot of" is HTML tools. Not that I consider myself "one of the HTML crowd either." What I am surely NOT one of is someone who believes that either the PG "txt70" format nor BB's proposed ZML format is a "good idea" for a couple simple reasons: 1) I personally find that trying to write to an "invisible markup" implied -- but enforced -- format without even any tools to check that "invisible markup" leads to "he said she said" arguments with the WWers where they claim "everyone knows" that XYZ is a requirement of txt70, say, but there is no documentation to be found to that effect. Personally I find it much easier to review explicit tags that I can actually read than counting invisible CR/LF "markup" to try to guess whether I'm going to make the WWers unhappy or not, and ultimately one has to negotiate with the WWers "is it close enough" to pass muster on the unwritten invisible rules of txt70 or not? 2) Neither txt70 nor ZML is "sufficient" to encode the kinds of things transcribers need to transcribe, and then they are forced to "make it up as they go along" anyway and then effectively, that part of the transcription is "write once" anyway. 3) The long long history of implied markup language, starting (loosely speaking) with nroff/troff is that a) people start with an implied markup language but find that this is insufficient b) add some field markings to overcome those limitations c) find that those field markings conflict with existing codings in txt files, d) add escape codes to work around those conflicts e) then find they need to add span markings f) find that those span markings conflict with existing codings in txt files g) now add escape codes for the span markings h) find that everyone has become disgusted by the complexity and "one off" nature of all these different markings, and having to keep inventing a new marking every time some new little need comes up -- leading to the realization circa 1970 that it is less of a hassle to simply introduce a single consistent explicit markup scheme for "everything" and that people should just "bite the bullet" and do so explicitly markup "everything." 4) Even if implied markup languages were a good thing there are dozens of them out there already and better developed and better supported by better programming and PG shouldn't keep going down the path of reinventing their own square wheel.