And everyone else, Martin, Jake, and Cindy, let's open it up to questions. I'll start. I'd like to see a show of hands. How many people here have used the book DTD? Wow, that's a lot more than I would have thought. How many of you are going to switch in the short term, do you think, to bits?

Awesome. More hands up a year from now, I hope. Okay, I think I saw a question somewhere in the middle. Right. Yeah, hi there. This is Damian Hess from Avalon Consulting. This is really a question for the people who are going from Word to the NLM XML using X-Tiles. How automated have you found that process to be? And second question, have you found any kind of best

practices or guidelines to give to your authors to make sure that that transformation is as smooth as possible? And I even have a third question. Is the workflow pretty much one way? Are you going from Word to XML? Are you also going from XML back to Word?

No. I'll answer your last question first and right now, no. We're not going back to the source document to make changes and that is not a best practice. As far as X-styling goes, we have members of our staff who are more or less proficient

with it. We have one editor in particular who is our go-to guy for more difficult projects. I have asked our editorial department in the past, if we could go back and just not X

-style documents, would you prefer to return to the good old days? And their answer is inevitably no. And then they say, well, X-styles is a lot more work, but it's a lot more work up front that results in a cleaner document. So I guess that's a pro-X-styles pitch on my part.

But your second question was, I might have to repeat your second question. I might even remember it. One was with how automated the conversion can be and also if you have any best practices or guidelines you can give to your authors to make sure that the work can actually get transformed.

Yeah, I had to zone out on that one. The guidelines that we provide our authors certainly precede our X-styling by a matter of 40 years or so.

And we're still running into the same problems. I think it's been touched on a couple of times here that authoring in the book world differs somewhat from authoring in the journals world. And book authors seem to have a lot more latitude in terms of what's an acceptable project.

I think that it behooves my organization to give our editors a little more authority over certain aspects of the publishing process. And I think that's not to disparage my employer, but I think that's something we could definitely work on.

From our side, the conversion to XML from X-styles is totally automatic in the sense that we don't do any tweaks to the XML on the back end for print.

We do not produce Word files back from our XML. And as far as recommendations for authors, mine are a little more technical, but I would say if it's not a table, don't make it a table.

But they'll make it a table. But they'll make it a table. People try to do things in Word, not understanding what the ramifications are down the road. So if you need something to be in a text box, please don't put it in a table.

If it is a table, please don't do it with tabs. And if it's an equation, if at all possible, do it in a format that can at least be converted to MathML down the road. So as close to MathType as you can get it is ideal in our workflow.

Yes. I'm Chris Maloney again. So I have a question about bits is out in draft form. And I guess I'm kind of wondering how late in the game is it. Is it an alpha stage draft or beta stage? How much might it change?

And especially after seeing Wendell's presentation, it seems like, yes, it seems obvious that work should be done to harmonize bits and other resources that are already out in the community. Jeff, as chair of the working group, do you want to take that one?

Well, it's 0.2 now, so we have eight points until we get to one. I know that's not a good answer. I think that we're going to have to see what the use is over the next few months and what kind of comments we get on the JATS list.

I really don't know how. I can't say whether it's alpha or beta. I know that when the working group met in person just after or during the hurricane, we thought we had things nailed down pretty good.

And we said, okay, well, we're going to put these things into an extension of JATS 1.0 when 1.0 becomes final. And so 1.0 became final, and I said, okay, let's make bits and roll it out the door in two weeks. And the working group said, wait a minute, we have some things to talk about.

And we got together and we talked together in two or three conference calls and did some things over the email until we came up with this draft. So I'm sure there are still some things to work out, but I'm not sure when we're going to get to 1.0. Probably we have to get to a point where we declare it and move on.

I'm going to speak as a member of the working group, but sort of unofficially my own personal impressions. The first is we don't have any firm timeline. I think I'm safe saying that because we really want to work based on feedback. If we look back on the history of JATS, really the NLM DTD,

we really didn't have a set timeline until we started to get to things like 2.2 and 2.3 because we began to see what the usage was. So I think part of it right now depends on what the usage and what the feedback is. I'm really going to stick my neck out with this next comment by saying that as a member of the working group,

and this is more of a personal comment, I would tend to guide the working group towards keeping any updates between now and 1.0 to the greatest extent possible, 100 percent backwards compatible with 0.2. So people who adopted early aren't suddenly stuck because 1.0 isn't backwards compatible.

I know even with JATS we've had discussions at what points we feel comfortable breaking backwards compatibility. And I think that's important to encourage people to work with it. It is not, I don't think we've stated this explicitly, it is not backwards compatible with the current 3.0 book DTD.

So you will have to make changes if you are used to using that. And Jeff, you've got your microphone on so you look like you want to follow up on my comments. Yeah, I think I want to agree with you that I think we're going to do everything we can to keep 1.0 or 0.3, 0.4, 0.5, whatever, backward compatible with 0.2 just for the reasons you said.

So the likely changes as we move forward in the draft would either be adding new elements or further greenification of what should already be a fairly green DTD. Tommy. Something else to more directly address.

Chris's comment, which is commenting on the issues that Wendell raised. There is the possibility of dramatic change. The suggestion that this book's model would be more useful to the world if it was more docbook-like

or more DITA-like or more TEI-like than JETS-like is a really interesting suggestion and something that perhaps the working group and the community might want to consider. But it does run contrary to one of the things that the working group flat out agreed on initially,

which was that it was going to be as JETS-like as possible. And in particular, it was going to take minimal work to take a JETS journal article and turn it into a chapter in a book. And we wanted the minimal number of changes to that.

And it is not possible to both write a tag set in which you can take an existing JETS journal article and make it a chapter in a book without having to do much, if any, work to it, and have a tag set in which you can take a TEI document and, poof, make it a chapter in a book

or a docbook document and make it a chapter in that same book. Not to mention, I'm not even sure what it means to take a DITA document or a DITA file set and turn it into a chapter in the book.

So I think although Wendell has raised a really interesting question, particularly with people saying, wait a minute, we don't want to make major changes, it's probably off the table at this time. Yeah, I would like to take everything that Tommy just said and underline it.

She just made a very, very important point. And I think it would be a big mistake if you took away from my presentation the thought that I think it would be a good idea for JETS or BITS to become TEI-like. That is not at all the idea here. On the contrary, I think the world is better served if JETS does what JETS does well

and BITS does what BITS does well, while TEI is doing what TEI does well. In respect to this, Chris used the term harmonization, which I think is actually really nice because the point of a mapping exercise would not be to obliterate the distinctions or to make it so it didn't matter which tags that you chose.

I mean if that's something that happens because it turns out that the differences between the two communities are only on a cultural level and have no ramifications at all on the technical side, then that would be fine. But I don't think that's very likely. I actually think that the cultural differences go hand-in-hand with the technical differences.

And what we need to do is the mapping exposes where you actually have benefits from choosing to be on one side of a boundary line versus another. So far be it from me to say that I'm actually going to go out there

and say that it should not be TEI-like. And in fact, I think that one of the things specifically to the point of scoping and the question about, for example, adding letter tagging into BITS, I think that would be a mistake. Personally, I think BITS is going to do much better if it tries to stay at a level much more generic and not trying to address everything at the level of the element semantics

in the same way as TEI tries to do and uses other strategies that are actually well known within the markup community for modeling semantic data in other ways so that it can manage scoping without having to go through this periodic shedding of new element types that everybody has to adopt and learn how they work.

That's not necessarily the best approach for BITS at all, even if it has worked very well for TEI. So what I'd like to see is a conversation about these things and exposing what these issues are all in line with what Tanya said because I think BITS is going to do much better if BITS finds its bitsness rather than tries to be something different.

Okay, great. Thank you. I suspect there are more questions out there, but I'm conscious of the fact that we've taken five minutes of the break and we want to keep the 3.30 session on time. So thank you very much to all of the panelists. And if you do have questions, the panel will be here during the break if you want to come down.