Marcello wrote:
Jon Noring wrote:
I would think and hope that DP will convene a formalized working group of the various experts and enthusiasts here and elsewhere to hammer out the DP Markup Specification based on requirements gathering and analysis, which is the proper way to do this.
I think design-by-committee is the wrong way to go about this. Experimenting markup with more and more complicated books and refining the specs along the way seems to me far more promising.
Experimentation can be done *while* the working group is working on the specification, in an iterative process. It is important that experimentation itself is guided by the requirements established by the working group in looking at the bigger picture which can only be done by formalized collaboration between the members representing the various stakeholders interested in this. Of course, the most important player is DP, which has to implement the spec into their work flow, and they will certainly have their own laundry list of requirements. Anyway, you and others have already made a great head start on the experimental side, as well as establishing the first proposed "beta" specification, PGTEI. The working group will not need to start from scratch, but will be able to build upon the proverbial shoulders of giants. And to address the issue that the working group will likely not get it perfect the first time (it won't) -- in an informal chat I had with Charles a while back, one strategy he brought up is to come up with a "version 1.0" of the DP Markup spec, and implement that in the DP workflow. Then, as production rolls along, continue to update the spec as necessary to handle problem texts. The issue of compatibility (forward/backward) between versions of DP Markup spec will need to be addressed, and may be solved by keeping version 1.0 simpler (a smaller number of tags) and then add tags as needed over time. We don't want to remove tags as time goes on (since we may have finished texts using the deprecated/removed tags), but rather add support over time as needed.
But that's the Cathedral vs. the Bazaar discussion again.
Yep.
To see a particularly disgusting example of design by committee just look at XSLT.
And to see another particularly disgusting example of design by committee, look at SGML and XML. And the worst of them all: TEI. Nothing good ever comes out of committees / formalized working groups. <smile/>
The DPMWG will have a more formalized and committed leadership structure, with weekly teleconference calls. From my standards working group experience, it's amazing how much stuff gets done during weekly teleconferences and the occasional face-to-face meeting (biannual or annual), while written listserv exchanges in a group like gutvol-* usually ends up going around and around in circles.
Teleconferencing will essentially shut out all non-us based people via the prohibitive costs or via the language barrier. Non native English speakers like me may have a better standing in a written discussion channel.
This is of course an issue. There are now very inexpensive and free ways to hold a teleconference via VoIP or similar. In addition, all teleconference meetings, typically 1.0 to 1.5 hours in length, will be scribed and written Minutes produced. In-between teleconferences we can discuss details on a group forum. It is possible to hold the teleconferences at a time which is convenient for those in North/South America and those in Europe -- it gets tougher to find a good time when there are those in Australia/East Asia to include along with Europe/Americas, but this can be worked out somehow.
From firsthand experience it is amazing how more effective technical working groups are when they can at least meet by phone on a regular basis. It is a social and psychological thing which enhances working together and group creativity, which I've yet to see in text-only working relationships. At first I was skeptical (being a strong introvert myself who has always worked "online"), but came around as I observed the importance of human interaction by voice and in person for *technical working groups*. It's amazing, really.
I would even ask someone like C. Michael Sperberg-McQueen to be an advisor to the working group
I don't know if the TEI people could advise us much.
I think they will be very helpful -- I know a few others who are very knowledgeable about TEI in an XML-based publishing environment who can help establish requirements. A couple people I know are world-class at XSLT/XSL-FO (I think one of them served a while back on the original XSL working group at W3C.) A close business acquaintance presently serves on the CSS3 Working Group at W3C, and is working on high- quality presentation using XML+CSS in his business. Having varied views on the DP Markup vocabulary is important.
What we need is not advice about the use of TEI as markup language but about the use of TEI as master format for automatic rendition into a wide variety of output formats. There is the tei-presentation list for this sort of thing but traffic there has been very light.
Yes, definitely! But note that other groups will also be helpful by providing requirements, including end-user requirements. Having sharp tech people from the accessibility, the library/archive, the ebook publishing, and related communities, will contribute to the bigger picture by providing requirements that they see from their unique perspectives (e.g., metadata from the librarian types.) If we want DP-TNG (TNG: The Next Generation) texts to be good for a wide range of uses, then we have to have people representing the various user groups to have their say in the global design of DP Markup. And I need to re-emphasize the importance to the embracement and success of PG/DP by involving the various user groups with PG/DP, and the inclusive working group approach is one of several strategies to achieve this "buy in".
The only person who could really help is Sebastian Rahtz.
Yes, definitely. I recall he and I chatted in private email a couple years ago (for what I don't remember). I'm not sure if he is subscribed to this forum. He is definitely very sharp and would make a great addition to the working group if he is able to participate in some capacity, even if only as an advisor. Jon Noring