XUG 2022: Session transcripts, Day 1

Granularizing BITS XML for Product(ion) Flexibility

Presenter: Cindy Maisannes, CFA Institute

Jenny: So, hi, everyone. I’m Jenny Seifert from earlier in the intro. I’m really happy to introduce Cindy Maisannes this afternoon. She’s going to talk to us about… She’s going to make me say, “Granularizing BITS and XML for Product Flexibility,” which is a case study from CFA Institute on re-architecting their BITS XML for richer reuse of content. Cindy is the Senior Manager for Publishing and Technology at the CFA Institute, where, for 15 years, she has supported the production of books and journals in digital and print formats fueled by eXtyles. Prior to her work at CFA Institute, she collaborated with faculty, staff, and students to build digital scholarly text projects at the Electronic Tech Center and the Scholars Lab at the University of Virginia Library. So thank you so much, Cindy, and go ahead and take it away.

Cindy: Great. Everybody can hear me, and everybody can see my screen? Hopefully. Scream if not, but-

Jo: You’re all good. You’re good to go.

Cindy: Great. Well, yeah, so thank you for calling out my title, “Granularizing BITS XML for Product and Production Flexibility.” I did have a moment of panic last night where I realized that “granularize” is not actually a verb, but it does appear in Wiktionary, so it has at least that level of credibility behind it. But so, today, I’m going to be talking to you about the background of our curriculum production at CFA Institute and going into a little bit of detail about the old way that we used to do things before, talking about how we’re doing them now, and then a little bit of a discussion of what we did right and what we did wrong along the way. So for some background about our curriculum, we do have several programs of study at CFA Institute. The most well known of these is CFA Program. And as a side note, CFA Program is actually 50 years old this year. We administered the first exams in 1963, which means that the first curriculum was released in 1962.

So the content of CFA Program and all of our other curricula, not surprisingly, was originally conceived and created as a print product. Up until about 10 years ago, that was exclusively the case. The curriculum content is unique in that it’s updated fairly significantly every year by a distributed pool of external SMEs. And because we’ve got such a large pool of external writers, we need an authoring platform that’s easy for everyone to use and doesn’t require additional licensing fees or user training. So having authors share their curriculum readings with us as Word documents has always worked best. We then reproduce the candidate study products from the ground up every year using eXtyles SI to convert to XML and other automated workflows for downstream conversions like Typefi for PDF production and some custom scripts to create EPUB eBooks.

So I’ll show you a bit about the old way we used to manage all of this content. Here, you’ll see a basic breakdown of what a curriculum chapter or a reading contains. And so in 2011, when we were creating our first XML architecture for CFA Program, we settled on dividing content up into individual documents based on two criteria, what kind of content was in the document, and what different parties might have authored the document or be retaining copyright ownership. So we settled on breaking these out into three different kinds of documents. Learning outcome statements were always authored by CFA Institute, but the text of readings could have been written by another set of parties, and the practice problems and solutions could potentially have also been written by a third set of parties. Each of these sections was created as its own Word document and was converted into its own book part in NLM Book 3.0 XML.

So within the learning outcome statements document, all of the individual LOS, or learning outcome statements, that were covered in that reading were presented in one long list. Literally, those items were tagged as a list in the XML, and the only distinction from other kinds of lists was a list content attribute specifying that this was an LOS list. The reading itself could be quite long, and at the end of the reading Word document, we would have glossary terms from the reading, alongside their definitions. Readings could be up to like 100, sometimes longer, pages, followed by all of the glossary terms, and then a third document included all of the practice problems and solutions, which were presented at the end of the reading in the print textbook. Like the LOS, these problems were all presented in list format in the XML, followed by another list of all the solutions. And we worked with Inera for a really long time to try to find a way of linking individual problems in the list to the solution that corresponded to it in the following list, but because the content was so complex and actually included other lists as part of the questions themselves, we were never able to find a reliable way of creating those links. So for what we were doing with this curriculum content at the time, this breakdown of content and the XML tagging worked well. There were some minor quirks and workarounds for specific content configurations that we would have to deploy at times, but in general, it was pretty straightforward and useful. So our CMS and production system architecture at this time was a customized version of SharePoint 2010 that we powered to run all of our automated production workflows. We’d have curriculum source files maintained as Word documents in SharePoint 2010, and then those would get sent out to eXtyles SI for conversion to XML, and then they’d get imported back into SharePoint, and the XML could then be workflowed out to Typefi for conversion to PDF and imported back into SharePoint.

So that system worked well, but it did have some limitations from the beginning, one of which was that SharePoint could only store XML as full documents. We couldn’t process sections of the XML files separately, and we couldn’t search within the XML. In 2013, we added the ability to convert curriculum XML to EPUB, but SharePoint couldn’t be updated to run those scripts through automation, so creating EPUBs required us to download all the needed XML and images out of SharePoint and process everything locally. And then finally, we launched the curriculum as courses in an online learning ecosystem hosted by BenchPrep. So to build a course, we would download all of our XML and images and send it all to BenchPrep, and then BenchPrep would convert those into an HTML course using a combination of scripts that they had written and just a lot of manual work. So over time, we began to see the need to update the system for a number of reasons, frankly. The most limiting factor we were experiencing was that SharePoint 2010 was reaching its end of life. We really rode it out to the bitter end with SharePoint, but it was so old, and the BizTalk functionality that moved content back and forth was so fragile that it was broken all the time, and our IT Department couldn’t support it anymore to even make minor updates. So this meant that we couldn’t upgrade any of our component parts of the system either, so eXtyles and Typefi were also effectively frozen. Whenever we’d get a new maintenance build of eXtyles SI from Inera, we’d end up just shelving it, because we couldn’t install it on the server.

Another issue that we wanted to improve in a new system was including EPUB and Learning Ecosystem HTML courses as formats that could be produced through automated workflows within the system, without having to download XML and images to process locally. I think if you asked any of our Production Team, they would probably say that it wasn’t too bad to have to run all of these scripts locally, but it was somewhat inefficient, and it was a little risky. People would assume that they had the most updated versions of the files already saved on their local machine instead of going through the hassle of downloading from SharePoint again, and I always got a little nervous about updates to files in SharePoint getting overlooked and lost.

Another inefficiency was the creation of the glossary within each program level. Glossary terms were maintained within the individual reading Word documents where they were introduced, and sometimes there would be instances of the same term getting defined in multiple readings, all with slightly different definitions, but there was no way of addressing that within the terms… With the terms only existing inside the reading XML files and SharePoint, which we didn’t have any ability to search for using text or Xpath, so we’d have to check for duplicate terms when the glossary for the whole level was created and then go back to SMEs to dedupe the glossary for us at that time.

These next two items were really huge in our need to update our workflows. When our first curriculum program was converted from print to digital course, it needed to be broken down into shorter lesson-length sections for presentation online. We worked with SMEs to create these chunking spreadsheets, which took the print readings and dissected them into often very messy divisions of content. We’d have to tell BenchPrep, “Okay, learning outcome statements 1 and 3 from this reading are covered in sections 3.1, 3.4, and 3.9, and they should be linked to practice questions 6, 7, 11, and 13,” and then BenchPrep would have to take our XML and slice all of that up manually as they were creating our courses. We hated it, and they hated it, so we needed to find a better way. And lastly, there was a huge inefficiency happening with our Exam Development Team responsible for the exam questions that test the curriculum content. They were frustrated that the curriculum was updated every year, because we had no way of flagging to them what was changing in the curriculum or where or how those changes might be connected to exam questions in the question bank. And so they wanted to know, if something changed in the curriculum, do we have any exam questions based on that specific piece of curriculum that would need to be reviewed to ensure whether or not the question was still valid? And because the curriculum was reproduced every year with no persistent identifiers in SharePoint to associate last year’s sections of content with this year’s, the Exam Team had to do a complete remapping of the curriculum from scratch every year to compare against to their question bank.

So we re-architected things, and this is the new way we’re creating content, which is now tagged in eXtyles as BITS 2.0 XML. Instead of print readings that were divided up into three long sections of learning outcome statements, reading text, and problems and solutions, we’ve now got all of these individual components being tagged as their own book parts that get saved separately. Readings have now been broken down into multiple shorter lessons, each of which is linked to the LOS being covered in the lesson and the individual practice problems and solutions testing that specific content. LOS have shifted from being a full list of multiple list items to being stored as individual learning outcome statements that are tagged as book parts. Practice questions are also no longer tagged as full lists of all questions associated with the reading, but are saved now as individual Q&A pairs, tagged as book parts, and associated either with individual lessons or with the full learning module itself. And instead of storing glossary definitions at the end of readings in which the terms are introduced, we can now save individual glossary terms and definitions directly in the database, which makes deduping easier to manage as we load content into the CMS.

So the gray boxes here indicate the division of how all of this content is managed as Word documents. A Word file contains these component parts in a specific order with LOS first, followed by the lesson text, then the glossary terms, and then problems and solution pairs. And RSuite, which is our new CMS, parses the components out in the proper locations in the database upon upload of the XML. Our updated eXtyles build allows us to tag problems and solutions using the BITS question wrap tag set, which means we can finally link questions and answers together without having to try and go through complicated logic of matching list items in order. And all of this tagging and storage in the database means that we’re now finally able to deconstruct the curriculum in various ways to be able to repackage it differently.

So this is the CMS we’ve migrated to. It’s RSuite, which is structured on an XML-aware database, and that lets us save content and metadata at more granular levels than we ever could before. The new curriculum source of truth is the XML in the database, no longer the Word documents themselves. And so you can see at the lower left of the diagram that RSuite has integrated oXygen Web Author as well as eXtyles SI for us to be able to update content. Minor updates can be made directly in the XML through oXygen Web Author, and more significant updates are made by exporting XML to Word through a custom workflow created for us that tries to match the XML tagging to eXtyles Word styling. Our production workflows are all automated and able to be run out of RSuite directly without having to download XML or image files, so Typefi is integrated for PDF production, the XSLT to create EPUBs is also integrated as a workflow, and we’re now able to run our own workflow out of RSuite to create the HTML package for courses in the Learning Ecosystem on our side without having to get BenchPrep to convert to HTML themselves and divide up content using the old chunking spreadsheets. This workflow in particular saves us a month of production time for each course we deliver in BenchPrep, so it’s been a huge boon for us already.

We’ve only really been working in RSuite for about a year now, so we’ve still got lots of systems we’d like to connect and new functionality that we’d like to add. We’d like to be able to connect RSuite to our enterprise web platform, Sitecore, to be able to push out curriculum content to the web as refresher readings for our charter holder members, and there could be other delivery platforms down the road. We’re also very interested in being able to integrate a taxonomy classification platform to help us do more robust reporting about curriculum content stored in RSuite. This would let us hypothetically pull together new content collections about specific topics that can be used as the basis for professional learning courses. And lastly, we’re now set up to be able to report back to Exam Development about what is different in the curriculum year over year. The book part content stored in RSuite has all the persistent identifiers associated with it in the database, so with the future integration of a comparison engine like DeltaXML, we could flag what’s changed in the curriculum and potentially link that to the exam question bank to flag questions based on that changed content.

So in terms of what we may have done right, I think there have been some benefits for product flexibility, specifically for candidates. Each year when production takes less time, that means we have more time to be able to give back to the content authors and reviewers and copy editors and exam question writers, so curriculum updates and exam question creation is able to have more time for development. And it helps to ensure that the curriculum is as recently updated as possible before it launches to candidates. So instead of us needing to take a year and a half to do production, and content having to be fossilized at that point, a year and a half before it launches to candidates, we can now do that faster. Automated production also means fewer human hands potentially introducing errors into content, which is always good.

And finally, customizing output formats is easy. So for example, print can include all of the Q&A together at the end of a reading, while the LES version online can have individual Q&A pairs linked to the lesson in which that concept is covered. In the future, we’re looking forward to being able to stand up new products and content formats much more easily using curriculum content out of RSuite. I will say that this is currently untapped potential of this new system and content architecture, but there’s increasing interest in it across the organization, so stay tuned.

And lastly, again, we can finally track persistent locations for pieces of content in the curriculum year over year. I won’t say “problem solved” for our Exam Team now, because the workflows needed to track changes still need to be fully defined, but we have the technology infrastructure to be able to accomplish this project, finally. On the production side, I think the benefits of our new system and content architecture are even more elegant.

First and foremost, digital output formats were baked into the system, and all of our workflows, and how they were conceived. This is, of course, a benefit to candidates too, since content is being conceived now as a digital product first as opposed to a print product that gets retrofitted to online delivery, but also, on the production side, with the content being tagged and stored as these more granular pieces, we can manage it a lot more easily. We’re not limited by having to deconstruct these 100-page-long behemoth readings into something smaller, which we were rarely able to actually ever accomplish before. We don’t have to download content to process it as a regular course of production now, so that’s good. Glossary deduping also happens in a more agile fashion at the time of upload to RSuite, eliminating a downstream bottleneck with duplicate resolution having to get fed back to SMEs as a waterfall process, and it powers easy, robust reporting. So information about the curriculum can be found via XQuery, and exported to Excel and manipulated there. It’s incredibly easy to move individual pieces of content across locations in the curriculum now, too, without having to edit the content out of one or more Word documents and add it back into other Word documents. We can just change the location and the linking in the database.

And lastly, we can now compile curriculum product formats at different levels of granularity, so a single lesson or a group of lessons together in a learning module or a topic, all of these have objects like figures and tables and text boxes and equations and footnotes that previously would need to be renumbered manually by an editor if we wanted to combine a different configuration of products together. But now we have all of that numbering being handled on the fly when the content is exported out of the system, so that makes it just a whole lot easier for us and for our Editorial Team.

We definitely made some mistakes along the way. First and foremost, we’ve learned not to let systems fossilize, waiting for the perfect time to upgrade them, because that time never comes. Lesson learned. We formerly had a rule that we would never contemplate upgrading any component piece of our production system architecture while we were doing active production of a curriculum product to try to ensure that we would never encounter unexpected system downtime during production, but unfortunately, that just meant that we never upgraded anything, since we were always in the process of producing something. And especially now that we’re producing more products than ever, we’ve just had to get comfortable with this risk for the overall health of our systems.

Our next mistake, I think, has been not staying in extremely close communication with our Curriculum Development Team in particular as we’ve been building the system and our XML content architecture. So almost as quickly as their team told us what content structure they would be using for their new digital learning module format, and we went off to build that structure in eXtyles and RSuite and Typefi and BenchPrep, the SMEs independently began to tinker with ways to change that so that what we built was no longer entirely accurate. We’ve had to alternately update our architecture sometimes, and sometimes just tell the SMEs that, no, they can’t do something they planned to do, and that gets frustrating for everyone.

Also, I think we made some bad assumptions about product formatting based on partial information from only one user group. So the list of learning outcome statements at the beginning of a curriculum reading or learning module used to be formatted as a list with alpha-lower labels, which was how the Exam Dev Team did their mapping of the curriculum to exam questions every year. They would refer to the 2023 Level I curriculum, reading 27, LOS A. And when we were able to assign persistent identifiers to the LOS for the Exam Team to refer to, we thought, “Great,” and we eliminated those alpha-lower labels in all curriculum formats for candidates too, only to discover that there are many other ways in which those LOS labels were getting used, and we didn’t know, including for candidates reporting errata in the curriculum, and Prep providers, so we made a mistake.

Lastly, I think we’ve still got a bit of figuring out the best way to track certain metadata information in RSuite and in our XML. Right now, there’s some metadata and semantic tagging and XLinks to other files that are tracked in our source XML files in RSuite, but because this information in the XML was basically invisible to users outside of our Production Team, we created metadata categories in RSuite that let users be able to access it without having to try to parse through an XML document. Unfortunately, we realized that it had become possible for the XML metadata to be updated when the RSuite version of that same metadata wasn’t. And thus, we’ve either got to remember to update the metadata in two places now when changes are made, or we’ve got to figure out a better way of doing this going forward. Now, I’m sure those are not the only mistakes that we made along the way, and I know we’ve got a bunch of people from my team on the call, so I welcome them to chime in with more, or to correct me where I’ve been wrong, but otherwise, I’m happy to entertain questions.

Jenny: Thank you, Cindy. That was a really… I echo Debbie in the chat, “What a great case study.” And there are a couple of questions, so I’m going to go ahead and start with question number one, which is actually a couple of parts, and so I think I’ll start with the first one, which is, you talk about, now, how you have this modular ability to take pieces of your lessons and move them around, and the question that came in was, “How do you put your content together,” right? So, how do you take these pieces and put them together? And then the part two of that, which is related somewhat, is, “Why choose book part and not book part wrapper “when you were deciding on your markup model,” if that makes sense, so I’ll go ahead… And Stacy, this question is from you, so if you want to chime in to clarify further to follow up on that, please feel free.

Cindy: Yeah, and I’ve already forgotten the first part of the question-

Jenny: Oh, sorry.

Cindy: I apologize.

Jenny: How do you concatenate the parts? Yeah, the bits that… Right.

Cindy: Right, so the individual documents are created as these lesson-length files, and then the content gets disassembled into LOS, lesson, blah, blah, blah in RSuite. When we do the recompilation process into PDF or LES or another format, it follows the order of the content in RSuite. So the content is all set up in the order that the curriculum should be compiled for that year in terms of the actual lessons themselves, and there are XLinks within each lesson that link out to the LOS that go at the beginning, or the problems and solutions that go at the end. So that’s the manifest of how all of the content comes together, which is by a combination of just, what’s the order in RSuite, and what is the logic rules of LOS go first, followed by lesson, followed by problems and solutions. Um-

Stacy: Oh, sorry. I was just going to give context to my question, is we have a lot of integrated resources with editorial teams, but different authors for all the parts, and they’re getting updated at different times. So that’s why book part wrappers work best, and not having a manifest where we have to update and process the book all at one thing at one time. So that was just some background to my question, but maybe you don’t have that use case.

Cindy: No, I think we probably do. It is one issue that we struggle with just in terms of having a more waterfall production system than we would like, where we have to wait for all of the content for, let’s say, a print volume to be completed before that volume can be produced at all. And so we’re always looking for ways to try and make that more agile and less waterfall, but I have to admit, I don’t think we considered book part wrapper as an option to be able to handle that. Perhaps we should have.

Jenny: Thank you. So Bruce has a question, but he’ll ask that.

Bruce: Yeah, I’m going to come off mute. As the content grows and changes over time, what’s your process for maintaining the integrity of the links? So for example, if one lesson gets so big, it’s split into three, how do you link to the right part? Or if some content becomes totally out of date and is eliminated, how do you make sure you don’t have links to it?

Cindy: Yeah, that’s… It’s been a challenge to really figure out the specific rules around this, as… Bruce and I talked about this project for years before we ever undertook it, and this was always the same question that we came back to of, how do you decide when something’s new versus just updated, and how do you manage all of that linking? And it’s been a huge project that we’re undertaking this year, in fact, because in the Level I of CFA Program curriculum, they’re moving a significant amount of content out of Level I, and so we’re having to update all of that linking for just a huge section of content this year. If it’s literally just a one-to-one swap, it’s not a big deal. We can make that, and RSuite updates all of the identifiers to link to the proper places. But where there are one lesson splitting into three, I think more often than not, we probably deprecate the old one and institute three new lessons and just reestablish the linking, which, we’d love to think there are better ways of doing that, but we just haven’t found them yet. So it’s a little more manual than I think we would ideally like.

Bruce: You have any kind of script that would automatically identify dead links before a publication? Or have you thought about that?

Cindy: Well… So yeah, actually, I think Trevor Hiblar is on the call, and I’ll encourage him to unmute himself if he can help me out with this. He’s our Content Architect, so he’s in the weeds with this every day.

Trevor: Yeah.

Cindy: I think we would get errors. Right?

Trevor: Yeah, so if there’s missing content, we have workflows that indicate missing content. Some missing content can be ignored for a test run if you’re trying to preview it, such as images. We can just say, “No, go ahead. “Produce the PDF so I can preview this.” If there’s missing content like questions or LOS, it’ll actually error and tell us, “Hey, you need to go fix this.” And so this is… One of the strengths that Cindy mentioned was granularizing this. We like to run a lot of the lessons and the learning modules before we run the entire book. And so this is a way that, as we work through the entire content, we can check and see what’s actually ready to go on the fly, and we can find those dead links before we get to the deadline and run the whole thing.

Bruce: That’s very cool, thanks.

Trevor: Yeah.

Jenny: I know that we are at time, but there has been a couple of questions that are around this idea of BITS as an appropriate model for this re-architecting that you did, and did you find generally that it was a flexible enough model to handle the content in the way you wanted it managed, or did you find any challenges with this transition to BITS?

Cindy: Yeah, we didn’t have any challenges. I think the one thing that came up initially as a recommendation from ORBIS was that, rather than use for LOS, and problems and solutions specifically, I think, they wanted us to customize BITS to effectively create copies of , but to relabel those as specifically LOS and problems and solutions. And we elected not to do that, because it seemed like it introduced unnecessary complexity that wasn’t really adding much, but there are ways in which it would be easier to display content in RSuite specifically. But in terms of the actual tagging model, I don’t think we’ve had any concerns at all.

Jenny: Very cool. Yeah, shout out for the Q&A tags in BITS that you all use-

Cindy: Quite heavily, yeah.

Jenny: Okay, any other questions before we wrap this up? I know Robin has a really good question that I think everyone at Inera is also interested in hearing, which… And maybe we’ll talk to you about this offline, Cindy, is if there were any particular issues or challenges you’re running into with taking BITS XML back into Word, so that’s certainly very interesting, but probably worth its own session, right?

Cindy: Also still a work in progress.

Jenny: Exactly. Well, thank you so much.

What’s Happening in JATS, BITS, and STS in 2022

Presenter: Debbie Lapeyre, Mulberry Technologies

Sylvia: Okay, so our next session is “What’s happening in JATS, BITS, and STS in 2022” with Debbie Lapeyre. Debbie is VP of Mulberry Technologies, which is a consulting firm that specializes in helping clients toward publishing and documentation solutions through XML, XSLT, and Schematron. She’s also involved in JATS, BITS, and NISO STS. She’s taught hands-on XML, XS- XSLT, DTD, and Schema construction and Schema courses, as well as numerous technical and business level introductions to XML and JATS. If you’ve been to XUG before, you know Debbie. And her hobbies include birding, pumpkin carving, parties, and many too many books. Take it away, Debbie.

Debbie: Okay, thank you. I’m bringing you the- Well, I think of as the annual update to JATS and BITS and STS, and I’m going to do them individually. But first, let me warn you about this talk. I only have 20 minutes, plus 10 for questions, and I could talk about JATS or BITS or STS for a week. Notice I said “or” there, and you have asked for “and” in 20 minutes. So, I realize I have a mixed audience here. Some of you are really interested in the geeky details, and some of you aren’t. So, there are going to be a whole lot of slides that I don’t talk, all right? They’re labeled. The idea is XUG is going to put these up, and if you wanted to see what they said, you can go back and catch them from XUG, got it?

Okay. JATS, the first one. Journal Article Tag Suite. JATS 1.3. Z39.96-2021. I told you last year, it revved. It did. We have a brand new standard published. We have new DTDs, RNGs, XSDs, and a redesigned Tag Library. If you haven’t seen it in a year or two, it’s worth going to look. But, what’s happened since is a lot more interesting. We’re working on two things simultaneously. We are working on JATS 1.4, which is the next regular release. And, we’re working on JATS 2.0, which is a non-backwards-compatible, “we can make it what we want it,” release.

Okay, but the interesting thing we’re doing, I think, is that it has occurred to us that the JATS 2.0 meetings are coming up with some dynamite ideas that are not non-backward-compatible. We just didn’t talk about them as part of the regular JATS. So, we’ve gone through the recommendations for 2.0, mining it for what we think could go into 1.4. And that’s what we’re discussing now.

All right. Some changes already recommended for JATS 1.4. We want to make permissions repeatable in more places. The French have pointed out to us that French Canadians and English Canadians both have permissions both in the same document. Whether the document is in English or French or both, the permissions are likely to be in two languages. So, it needs to repeat, and it needs to have a language attribute. Thank you, Canada. We heard you.

MathML 3 committee has come up with new modules. Use them. We’re using the, I don’t know, 2004 set, something like that.

ALI, Access and License Indicators. The ALI people have also come up with a new recommendation. Use it. It’s got at least some new attributes. Now, that’s what we’ve agreed to, and that’s all we’ve agreed to. But, here’s part of what we’re discussing. Crossref has pointed out that institution is all very well, but sometimes, your institution is a university that has a campus, that has a department, that has a laboratory, and you want to talk about just the department or the laboratory. You need a way of breaking down those units. We have had a request that <anonymous>, which is currently an empty element in publishing, have content because they’re using it in some very clever ways for anonymous peer review. And, we’re discussing that. I think it’s clever, and we’re adding <legend> from BITS. I’ll talk about that when I get to BITS.

In Draft. This is one of the most exciting things, but I’m not going to talk about it. It’s complicated. We have decided that there is a world out there doing multilingual documents. The Canadians have told us that in French and English. SciELO has told us that in Spanish and English and Portuguese. And then, the European Union people said, “Well actually, we’ve got Romanian and German and-” Okay, we get it.

So, we want to be able to care for a journal article when the whole thing is in two or more languages or substantial portions are in two or more languages. I have this section in French followed by this section in English, and the idea is if I could handle them, I could say, “Look, show me the whole thing French and English mixed up together.”

Or, “I don’t read English. Show me only the French document. Pull that out for me please.”

“Do all the searching only in English because if you find something in the French and bring it back to me, I won’t be able to read it. I don’t read French.”

That’s the goal, and I think we’ve done it. It’s in two pieces. Multilingual metadata. Basically if it’s already there, you just ask it to repeat. I want an abstract in Romanian and an abstract in Greek and an abstract in Hungarian. Fine. I’ve got three abstracts. They have language attributes. All metadata needs to do is repeat. Text, however, is a little more interesting. Textual structures, if I have alternate sections in French and English or Greek and Romanian or Spanish and Portuguese, they don’t have to be co-located. A single language, you may not do all of the Portuguese followed by all of the Spanish. You may intermingle them, okay? So, no kind of wrapper element would work. And, we’ve come up with an attribute solution that I’m not going to tell you about, but it’s here.

Okay, next topic. “Changes to Collaboration.” Shout out to Joni here. She said that we’re talking about how elements ought to be used. Well, <collab> is such a perfect example of how elements ought not to be used. When <collab> was created – and I know, I was there in 2002 – what we thought it was was the name of the collaboration, okay? Moose and Squirrel Department, all right? Well, people put all kinds of junk into it. They put lists of contributors, and they put addresses, and they put footnotes, and they put – You name it, they put in it.

So, the proposed solution that we’re going to be discussing is to deprecate current <collab> and <collab> alternatives altogether and create some new elements to do what the old elements should have done. <collab-name> will be what <collab> was supposed to be. The name of the collaboration. All you want is that little string that’s its name. You’ll be able to find it. And <collab-wrap> will hold all those other things, like the 120 participants that you thought was a good idea.

I’m excited by this one too because … “Citing Standards.” We obviously made up how to cite standards out of whole cloth in JATS in the early 2000s. And we did a terrible job of it because we had no idea how standards were cited. But then, STS came along and they said, “We’re the standards people, and we know how standards are cited, excuse me.” But, it’s done with something called the “Standards Designator.” And that is just a string, but it includes the originating organization, the standard number, and the year. And they have called it “<std-ref>.” The suggestion that we’ll be discussing is that JATS add <std-ref> to citations. I hope we say “yes” to this one.

Supplementary material has always been a problem. And we split off a subgroup on supplementary material to talk about it, and they came back and said, “Look, there’s no such thing as supplementary material. You just have figures, all figures.” And, some of them you say, “By the way, I’m supplementary.” You don’t make any difference in how you tag them. They’re just there. Similarly tables, similarly sections. And that would deprecate the current supplementary material metadata elements, which are <supplemental- <supplementary-material>. Oh, interesting. That should be <supplementary-material>. And the thing I find intriguing is I fixed that last night, but there it is, wrong. <supplementary-material> and <inline-supplementary-material>.

Okay, attributes also are going to change. @xml:lang has been added to <permissions>. I told you about that. We need the French permissions and the English permissions in Canada.

We’ve added some vocabulary attributes. We have a new value “interview” for @article-type.

And an interesting one, particularly I hope for Cindy, @question-response-type used to be a fixed list, and that’s nice, but there are lots of @question-response-types that aren’t there. So, we’re adding the value “custom” to this.

At this point, I’d like to take an aside because you may not know how the custom value works, all right? If a schema gives a list of values, all right, it’s in the DTD that your color is red and blue and green, and therefore, you can say <ribbon color=”red”> in your document. There’s no way to add another value like chartreuse or purple or yellow without changing the schema. And you people ought not to be in the business of changing DTDs and schemas. So we’ve given you, for any fixed list, a new value “custom”. So, the DTD says the values are now red or blue or green or custom, and there’s a @custom-type attribute. And you can see here at the bottom of the page how that works. I have a ribbon with color custom. I have a custom type that tells me, “Oh yeah, by the way, that’s purple.” This will allow you to have a fixed list because most of the time, we are red or blue or green. But, on those rare occasions when we need to be yellow or chartreuse or purple, we can do it. And, I’m hoping, Cindy, that you find this useful for your question types.

More attributes. Article types have changed a lot since 2002. We have data papers and collections and protocols and community comments and expressions of concerns and Jupyter notebooks that we don’t even quite know what to do with yet, but we have them. And so, we’re looking at expanding the suggested list. It’s only about 20 items now. We’ve got more than 50 to discuss. We may not end up taking all of those, but you see the direction. And that is what’s happening in JATS.

The exciting part from the point of view of 500 feet is we are trying to bring into the next release all the cool stuff we came up with for 2.0 that will fit, ’cause some of the cool stuff in 2.0 says, “Get rid of these six elements. Replace it with this one.” And that’s not backwards compatible. We can’t do that.

New topic. Yes, still on track.

STS- Oh, this one is exciting, people. I actually have something to announce. STS, for those of you who don’t know, is the JATS family for standards. It comes in two flavors, Extended (XHTML and CALS tables). Interchange (just XHTML tables). The status is– Well no, ignore this status.

Aside. We have version 1.0 now. Ideally, you’d figure the next version would be 1.1, but it’s not going to be because NISO STS was based on ISO STS, and they already did a 1.1. So we said, “Phooey, you know. We’ll skip. Software companies do this.” You know, there’s never going to be a 10 or 11 or whatever. NISO STS 1.0 were going to be when it revs NISO STS 1.2.

Last year, I told you this was nearing completion. The committee voted the final change in October last year. Mulberry made the DTDs, the XSDs, the schemas, the tag library version 1.1. Standing Committee approval November last year. Mid-February 2022, notice we’ve changed years, the Standing Committee approved it, and it went out for public comment. And, in my cloudy crystal ball, I said, “If STS 1.2 standardization process starts in February, we should have a new STS by June.”

Yeah well, nothing has changed in the models or the documentation since February 2022. But, here’s the slide that tells a complete lie because these slides were due on the 20th of October, and this was true on the 20th of October. But on the 21st, things got better. NISO 1.2 survived public comment.

The topic commit- NISO Topic Committee approved it. The Voting Pool members approved it, and NISO was going to request ANSI approval in mid-October, which they did. And, ANSI might or might not come back, and ANSI approved in a day, and we are approved. There is going to be, as soon as and fast as we can publish it, a new STS standard. Applause to the people who made that work and made that happen. This slide is wrong. We’re going to have it.

So, what does it take to make it happen? Well, we need new DTDs, XSDs, DTDs, RNGs, tag libraries with a new publication date. A bunch of wording changes, and then we can publish it and release the non-normative materials on NISO.org.

Bruce asked me, “Could that possibly be done by XUG?”

And, at that point I said, “Bruce, we got word Friday after stoppage of work, and XUG is Wednesday. No, it can’t.”

So, I’m sorry Bruce. We didn’t make it. But, there is a Standards forum on the 14th of November, and we will be way early for that. It will be done probably next week. Yay, people.

All right, which brings-

Bruce: I believe, Debbie, the precedent is that the 1.0 DTD has an official release date of 10-31. Halloween. I believe that is now your new target for this version as well?

Debbie: Yeah, I have already- The DTDs, RNGs, and XSDs have already been done, Bruce. Although they’re not released. And yes, the official date is 10-31-2022. Halloween again! Yes! You’re right. That’s for me. Thank you.

Anyway, what’s new in STS 1.2? The same things I said last year, so I’m not going to talk about any of it. If you want to see what’s new, it’s still new, and it’s still good, and it’s here in my slides, untalked.

So, I got five minutes, just about. What is new for BITS? This is kind of exciting too. BITS 2.1 has been published. It has new non-normative materials, DTDs, RNGs, XSDs, and the same redesigned Tag Library JATS has, which STS will also have, by the way. And, that’s the part that isn’t finished yet. If you haven’t seen the redesigned Tag Libraries, they’re good.

What is new and cool in BITS?

Well, we finally added <legend>, which got requested for JATS and turned down, but STS wanted it. And anyway, this is an overview slide. Let me take you through them one at a time.

<legend> is a key or a where list or a variable list or a symbol chart. You have them for equations and figures and tables and graphics, saying, you know, “Where A is the angle of, and B is the angle of and-” Okay? They are now official- An official structure. Interestingly, the <legend> structure doesn’t have anything except an overview as unique and different. It can have titles and IDs and like that, but it then uses def lists or tables or whatever you would’ve used before. But, you now know it’s a <legend> and can associate it properly with its figure or table or whatever.

BITS has a new element, unlike anything JATS or STS has, called <content-version>. It occurred to BITS people that book versions and book editions were being treated the same thing, but they’re not. So, <content-version> is a new element that will act for books and book parts the way article version does for articles. And, there’ll be a version alternative, so you can have three versions going at once, which people do.

Ah, this is exciting, and this has already happened in JATS and already happened in STS and now it is happening in BITS. The definitions of <source> and <part-title>. <source> and <part-title> are two of the citation tags. They’re inside a bibliographic reference, and they used to say, you know, “The <source> of the book is Moby Dick, and the <part-title> is chapter three.” Okay? But, that was all defined in terms of document, and that’s not what our world is anymore. So, we just redefined these. They’re now a portion. A <part-title> is a portion of a larger resource. And, I don’t care if that’s a podcast or a module in a course or an example in a book or whatever it is. There’s something bigger around that I’m a part of. And that bigger thing is named in <source>. And this too is now the title of a resource. That’s supposed to be the title of a document? I’m sorry, but podcasts, however we view them, are not documents.

This has an interesting side effect. We’re now deprecating <chapter-title> because it’s not a <chapter-title> anymore. It’s a <part-title> for a book.

<processing-meta>, again, is something that JATS and STS have added, but BITS added it too. This is kind of a “glee bird weirdy.” It’s an element that is not part of the content or the structure or the publishing metadata of a book or a book part. What it is is information about the XML file itself at the file level.

<extended-by> and <restricted- by> are specifically so you can say, “Look, we’re following the PMC recommendation or the Inera Guild’s recommendation or the JATS4R recommendation, and here’s what that recommendation is, and here’s how it restricts us.”

You’ve also got <custom-meta> in there, which people have used to say, “Well, here’s the conversion vendor I was using, or here’s the conversion process I was using, and if I was being converted by eXtyles, here’s the version of eXtyles I was using.” Okay, you’ve got lots of metadata now that people have been wanting about the file, not about the document?

Now, there are a bunch of attributes on this that say things like, “What @tagset-family am I part of?” That makes more sense on JATS and STS, which have more than one DTD in the family. BITS is fixed to BITS.

@table-model. Are you using “xhtml” or “oasis” or “both”? Which you’re allowed to do.

@mathml, again, in JATS and STS. This is an, “Are you using 2 or are you using 3?” Well, BITS is fixed to 3.0, so no question.

And, maybe even more interesting, @math-representation. How many ways inside this document, not in our DTD, not in our whole database, am I using to make math expressions? I’m using images, I’m using LaTeX. I’m using MathML plaintext and images. Tell me in English for human readability what you’re using.

Okay, other element modifications, I’m not going there. There are some cool attributes.

I do want to talk about DTD version. It used to be fixed so you set it to whatever the latest was that you were valid to. And that was a real problem for people who had big databases, because we’ve been really careful to be backwards compatible. So, if you’re at 2.1, you are going to be valid to 2.0 as well, okay? So now, it’s a list of choices so that you’re not restricted. If you’re 1.0, you know you’re 1.0. But, if you’re 2.1, you’re 2.1 or you’re 2.0, or two however many. You’ll be valid to those, we’re being backwards compatible.

@hreflang is an attribute we borrowed from HTML. It’s not the language of the document or the language of the related thing you’re in. It’s the language of what you’re pointing to. Here it is in the context of a <related-article>. I have a <related-article> over there, and my <related-article> is in German. Implication, I’m probably not. I’m probably in English or Spanish, but the thing I’m pointing to is German. And, if you’re going to follow that link, you might want to know that.

Yeah, there are more. My request here to all of you is- There’s where you find the tag sets. Remember, XUG will have these slides up. But, comment. JATS and STS are both under NISO control, so they have a specific comment form and process, and you can put your comment in. BITS doesn’t, but it uses JATS-list, as does JATS. If you don’t have something that rises to quite the level of a formal comment, but you want to ask, ask for it there. Make a comment. How would you like this to work?

And, as when I practice, I’m two minutes over.

Liz: We build an extra time for that, Debbie.

Sylvia: Yes, we do. Thank you, Debbie. So, I’m going to just re-spotlight myself. No, apparently I’m not. Never mind. I’ll pin myself. Maybe that’ll work.

Debbie: Okay. I’m looking at one of the comments, and Robert Wheeler wants to know, “NISO STS tag library too?” Oh yeah, that’s what’s- That’s what we’re working on right now, Robert. That’s why we can’t release the DTD and the RNG and the XSD, which are done, because the tag library and the standard aren’t. But when it comes out, it will have that same brand new structure that you’ve got for BITS and JATS, and yeah. You’ll like it.

Robert: I wasn’t demanding.

Sylvia: They’re so nice and navigable. I love them. Sorry, go ahead, Robert.

Robert: I wasn’t demanding. Sylvia had shared the other two, so I was like, “Wait.”

Debbie: Wait. STS is going to have it too. Absolutely. And, they don’t yet. And, they won’t, sorry Bruce, by the end of tomorrow. But, within the next two weeks, we definitely will.

Sylvia: OK. I do not see any questions for Debbie in the chat. Does anyone have questions that they would like to ask with their voice?

Debbie: That’s what happens when you talk too fast. Everybody’s too busy scrambling to listen, and they don’t think of questions.

Jenny: Sylvia, I think I would just like- I would just like to give a shout-out for the attempt to start to wrangle <supplementary-material>. The wild west of <supplementary-material> for sure.

Debbie: Well the group got together to make proposals on it, and what they discovered is no three publishers define it the same way. So, what we’re saying now is in the days of electronic articles, you’ve all got to have it there. And, if you want to mark it as supplementary so your system can keep it out of the print, fine. But you want to be able to find that if you’re reading it online. You don’t care that those three extra tables supplementary, you want to go read them. So, put them all in the article and just say, “This is supplementary.”

Jenny: It’s nice to have a little more guidance rather than just having someone ask us, “How can we mark up <supplementary-material>?” And then, our response being, “Good question.”

Debbie: Mark it up like what it is. If it’s a section, mark it as a section. If it’s a figure, mark it as a figure. But, what that means, as Charles is thinking here, “Damn, now I’m going to have to deal with them.” Yeah, you are.

Charles: I know that there are people that are using that to get things out of the file so that they can have manageable file sizes. And, that’s actually a really good use for people who have XML that’s, like, well over four or six megabytes.

Debbie: Well sure, and if you’re something like a data set, the odds are good you’re not going to want to put that. But, we’ve got all kinds of external links for that, you know. “Would you like to see the original data? Follow this link.”

Charles: But I mean, even if- But, if it’s just text and things like that, text and tables and things that would normally be in the file- The file itself is too big to work with, and-

Debbie: Again, you’ve got nice external links for that. You know, this will work for the people where they have little three-page articles, and we add two pages by adding two more figures. It won’t work for the multi-megabyte, approaching gig range, article. And they exist. I know that. Yeah. But, we’ve got all kinds of- JATS has lovely – and BITS and STS – external linking mechanisms for that.

Charles: Well, I’ll just- There are just people I’ll have to let know like, “Oh, that’s not going to work in the future.”

Debbie: That’s not going to work for you. It’s a great idea, but it won’t work for you. Yeah. Well, the original <supplementary-material> and <inline-supplementary-material> were used for metadata anyway, and they’ll still be available. You want your metadata about that figure? Here it is. You want your metadata about that section? Here it is. And, there’s an external link. It’s over there.

Sylvia: Okay. Do we have any more questions for Debbie in the next 3 minutes?

Debbie: I think what we should do with the next 3 minutes is you should put Robert and Bruce up- Their pictures up on the stage, and I- We should all applaud like mad ’cause NISO STS is out, guys. And they’re the chairs. Robert and Bruce.

Liz: Congrats, guys.

Sylvia: Not to be confused with Robert the Bruce. Where is Bruce? There’s Bruce.

Debbie: Yes. Well, that has been hard when you go Bruce and Robert, Robert and Bruce. Oh, right. Not the… Yes. Not the historical figure, but well done, guys. Hard fought fight.

Bruce: Thank you. It was a team effort by the working group. And credit to everyone who sent in suggestions.

Debbie: Oh, yeah.

Robert W: And Mulberry.

Debbie: Thank you.

eXtyles+: A New Partnership with J&J

Presenters: Michael Casp, Allegra Torres, and Jasmine Trinks, J&J Editorial

Liz: Okay, great. Well, welcome back everyone for the final session of the day, which is “eXtyles Plus: A new partnership with J&J” from our colleagues at J&J Editorial.

So to introduce the three speakers from J&J, we have Michael Casp, who is the director of business development. He, his background is in production workflows and peer review management, and he has worked directly with several society, commercial, and open access publishers. In his current role, he collaborates with customers to build optimized solutions to support their publishing programs.

Allegra Torres is a senior copy editor and team lead at J&J Editorial. She works on multiple copy editing and proofreading projects covering everything from medicine to engineering, but she remains a devotee of the Chicago Manual of Style. Good to know.

Liz: Jasmine Trinks is a copy editor and team lead at J&J Editorial. She works on several different copy editing, fact checking, and technical editing projects in fields ranging from oncology to physics and she lives in Chapel Hill, North Carolina. So, welcome to our guests, and thank you very much.

Michael: Thanks Liz. Hi everyone. Michael Casp here. Looking forward to talking with my colleagues Allegra and Jasmine about how J&J’s partnered with Inera to offer something a little bit different than what we’ve been able to offer before and we’re calling it eXtyles Plus.

So first, a little background on J&J Editorial. For those of you who aren’t familiar with us, pictured here are J&J’s founder, founders, Julie Nash and Jennifer Deyton. Julie and Jen started J&J in 2008 after several years previous of supporting peer-reviewed journals, and they really saw an opportunity to offer professional managing editor roles and publishing services to the journal community and took the lead in developing best practices in how journal offices interact with stakeholders and, and use peer review software. J&J found this niche and over the years we added related services for journals and books and other scholarly communications like copy editing, production system support and consulting. All right.

One year ago, Wiley acquired J&J Editorial to add a publishing services company to their stable of publishing technology offerings. Within a few weeks of the deal closing, Liz and Bruce reached out to J&J’s leadership team to set up some get to know you calls, and it was pretty quick that we, we all saw that there was a lot of value in combining Inera technology with J&J’s copy editing and production staff to offer publishers a really great product.

So, we started piloting eXtyles editorial features on an existing production project to test this hypothesis. Allegra’s going to talk a little bit about this project with ASTM later on. This new relationship with Inera has also changed the way I sell J&J services.

So, earlier this year I was talking to a customer who was looking for improvements to their production process. The algorithmic pre-editing they were getting from their vendor was not quite what they wanted and it wasn’t really as customizable as they needed it to be to be a better fit. So, you know, I thought, well, Inera can fix that. So, I pulled Liz and Bruce into the conversation and as we talked to the customer it became clear that, you know, they didn’t want to run eXtyles themselves. They didn’t have the bandwidth or, or really the interest in doing that. Their current arrangements was just to send their manuscripts off, get them back pre-edited. So, sort of on the fly we came up with this idea that, oh well we’ll do it for you. J&J staff will use eXtyles customized for your journal and we’ll run the automated pre-edit for you. Might even resolve some of the things that eXtyles flags for us so that you know, when we send the manuscript back, it’ll be cleaned up and ready to go.

They quite liked this idea and eXtyles Plus was born. So, this’ll be the Mineralogical Society example that Jasmine will talk about later on.

So, what are we really trying to address with this combination of J&J and Inera? You know, I talk to publishers all the time and I try to coalesce sort of the concerns I’m hearing into some groups here on this slide.

People are looking for speed and automation, you know. No surprise there.

People want research integrity. Which we find, you know, eXtyles reference validation definitely gives us a leg up on that.

People need process flexibility. You know? I mean, feels like we’re always in a moment. I mean, ever since I’ve entered the industry we’re always in a moment of change. So, you know, we have to be flexible and with the content types we’re working on and linking to, people need bandwidth. As things grow and change, they, the ability to add J&J’s staff alongside, you know, Inera’s technology, is really interesting for folks.

People are obviously thinking about standards and how to align with the best practices. eXtyles is great to help us, you know, get things standardized. People are, you know, concerned about accessibility, which eXtyles definitely supports by adding a lot of structure to documents. And J&J also has other accessibility features that we can add at different points of the workflow. And of course people want interoperability with their existing process. A human editor editor can flex to work in all kinds of processes and workflows in ways that, you know, a piece of software might not be able to in the timeframe they need it to.

So with that, I’ll stop and I’ll come back later to talk a little bit more, but for now I’ll pass it off to Allegra and Jasmine to talk about a couple of their projects that they’re working on right now.

Allegra: Awesome, thank you. So, hi, I’m Allegra Torres. This is my esteemed colleague, Jasmine Trinks. I, I’m on the ASTM team as previously mentioned and Jasmine’s on MSA. And the two of us have different experiences with incorporating eXtyles into our project workflow. So, hopefully we can shine some light on that. So on the ASTM team, we handle copy editing for ASTM International, which is an organization that develops and publishes technical standards for a wide variety of materials, products, so on. They have multiple journals that we handle from editorial to production. And this is an established project as Michael mentioned, that has been had a steady copy editing team for a while. eXtyles was not part of our original process. So, when we were bringing that on, it was interesting seeing how that got incorporated into our workflow. Prior to eXtyles, the copy editors did all of the manuscript cleanup and formatting manually before doing the very detailed, very thorough copy edit. Jasmine’s team on the other hand, is the more recent team to adopt eXtyles.

Jasmine: That’s true. Thanks Allegra. So I work on the MSA team, so for the Mineralogical Society of America on the journal American Mineralogist, which is the flagship journal of the Mineralogical Society and has been continuously published since 1916. The journal’s home to some of the most important advances in Earth and planetary sciences. As of right now, we’re handling a technical edit or a pre-edit for the journal, which is sent to us via eJournalPress. We run eXtyles on research articles and then send them back to the client for copy editing. And now I wanted to talk a little bit about the onboarding process with MSA, cause it’s been sort of a, an interesting experience. But we’ve all come to really value eXtyles in our workflow. So Inera sent us the first eXtyles build in July 2022, and Jenny at Inera conducted a virtual group training session with our CEs, which was really helpful, really thorough.

We ran into some challenges, one of them being that with the Wiley acquisition, we had to have some of our laptops changed out, which meant that some of our copy editors had the 64-bit version of Word instead of the 32-bit version, which meant that they could not run eXtyles. So, we had to work on that for a bit. We had to troubleshoot using eXtyles with OneDrive. We discovered that eXtyles will not run with OneDrive syncing turned on. But, after developing workarounds for these hiccups, we began working on practice papers with a lot of success. Copy editors completed several practice papers and sent them to Inera and the client for feedback. The feedback was returned from the client with several issues that needed to be addressed by both an updated eXtyles build and updated direction to the copy editors. Inera then sent a new build in late September, and we’ve been getting our copy editors acclimated to the new version, and are now working on live papers, which so far has been going really smoothly, which is great. Allegra, would you like to talk a little bit about onboarding for ASTM?

Allegra: Yes, as you know our onboarding process was similar in that we ran into most of the same challenges that the MSA team did. The 64-bit Office, the OneDrive syncing. Once we got through those, it was pretty smooth sailing from there on out. The main issue that we ran into after that, was that we started using eXtyles right around the same time that we also had a big staffing change in our team and a very big backlog of articles that we had to get through. So, this was perhaps not the ideal circumstances to learn new software, but we made it through, backlog’s clear, software’s learned. All is well. Unlike MSA also, the client was not involved with the creation of our particular build of eXtyles. Inera worked directly with our copy editing team to build something based off of the style guide that we already work from. And incorporating eXtyles into our workflow, in terms of how it affected further steps down the line, didn’t cause any issues for the typesetting process, or for our production people. So, that was very nice. As far as copy editing goes, Jasmine would you like to touch on how MSA does copy editing?

Jasmine: For sure. So we’re going to talk about a little bit about the actual copy editing requirements for these projects. To a certain extent, requirements for MSA are still evolving, because we’re in the early stages of our relationship with the client, but as of right now we’re working to ensure precise formatting of headings, tables, citations, and other parts of research articles. And accurate verification and formatting of references in the Harvard style. One unique thing about working with MSA so far, has been direct feedback from the client during setup and onboarding. So that Inera could better customize eXtyles for their needs. Specific direct feedback from the client is not always a given, as Allegra and I have talked about before, so we really appreciate that aspect of this project. An example of that is we recently got some feedback from MSA that they want post-processing cleanup run on their articles, which removes Word text shading and eXtyles tags for a cleaner look that’s closer to what the articles will look like in print. Which is for now what MSA is looking for.

For us so far the eXtyles user interface has been intuitive and easy to use. It’s easy to see which processes have been run on a file and which have not thanks to the the helpful green check marks next to each process. And so far we’ve found that eXtyles takes a lot of the grunt work out of technical editing and ensures consistent formatting. And on this slide you’ll see an example of one of our research articles before and after eXtyles processing. So this particular slide is just several paragraphs with headings, text, and reference citations and table citations. One difference is once we actually run post-processing cleanup, we won’t see the the Word text shading on those. And with the next slide we have a screenshot of the reference list before and after eXtyles processing, and as copy editors, we just really appreciate all the work that eXtyles does, especially with PubMed and Crossref and making sure all those links are correct and everything’s just where it’s supposed to be. Cause that’s a lot of work for one copy editor or two copy editors to do. Allegra, did you want to show some ASTM examples?

Allegra: I certainly do. So as you can imagine for a group that deals in technical standards, they have very detailed, very rigorous requirements for their copy editing. So, we divide our workflow basically into two parts. The first part being the technical edit, very similar to what Jasmine and the MSA team do, which is just sort of the initial intake formatting of the manuscript, checking references, checking callouts and citations. And then, once that’s complete, then we actually move on to the full copy edit. One of the fun things with this particular set of journals, is that they use both the Vancouver superscript number citation style for some journals, and then, the Harvard author-date style for another journal. So eXtyles has been fantastic for keeping track of that. When we load into, you know, start using it, you basically choose which journal it’s going to be, and from there on out eXtyles does the job of enforcing that particular reference style, which is phenomenal for just keeping people from making those kind of idle mistakes. I have seen authors use both styles in one paper and it gets very confusing at that point to remember which journal you’re working on.

So, the example that I have here is the Harvard style, the author-date. With these, because we’re also checking all of the callouts, making sure that everything has been called out accurately and correctly, having eXtyles be able to flag instances of references either being cited and not appearing in the list or appearing and not being cited is invaluable for copy editors. Particularly when we’re working on papers that have very long reference lists, which is not uncommon for engineering papers. The next slide, I believe, has our, this is the Vancouver superscript number citation style. Again, having eXtyles like do sort of the pre technical edit checks has been great for keeping track of these things. It has been pretty good for formatting references. We do have a lot of more obscure reference types. Authors like to cite a lot of unpublished conference proceedings, standards. Sometimes standards that like only exist in their country as opposed to international ones. So, some of these can’t be as easily formatted by eXtyles and can’t be verified in Crossref and PubMed, but eXtyles at least can draw attention to those, try to format it the best they can, and leaves a lot of helpful comments for things to look at when you’re working through the reference list.

And I think the last one that I have here, is we also check all of the figures and tables and eXtyles has been phenomenal for catching when the author has failed to call something out or perhaps called something out in the wrong order. And in terms of how it’s affected our overall process, it doesn’t replace the technical edit, but as Jasmine mentioned, the automation of these tasks takes a lot of the bor- kind of rote mechanical work off the copy editor’s plate, which leaves you with more energy to focus on, you know, tricky grammatical questions and finding references that only appear on the internet once and never again.

Jasmine: Never to be found. No, just kidding. One of the major benefits of eXtyles we’ve come to appreciate through this process, is its customizability and flexibility with different builds and so many different options for running eXtyles, we can successfully use it to deliver a satisfactory product to very different clients. And looking forward to our future relationship with Inera, we’re looking forward to continuing collaboration on these projects, and getting to know the software even more.

Michael: Awesome. Well thank you Allegra and Jasmine for laying that out. Yeah, we’re really excited about what eXtyles unlocks for us and our customers and you know, for both these projects we’re really just using the editorial features. We’re just starting to look at some of the, you know, XML export features as well.

And, for an example of that, we’re actually talking to a customer right now about something like this. So, for this project, this is a current J&J customer. We, do copy editing on their society news publication, which has some scholarly flavor to it, research and references, but it’s not journal content. Pieces are shorter, and they have production schedules on the order of like a couple of days rather than, you know, a few weeks or months. And in certain parts of the year, so like around society events, annual meetings, things like that, the timelines can get even more compressed as they do live event coverage. So this society publisher approached J&J to ask about some possible improvements to their process in order to simplify and streamline their workflow. And they were hoping J&J could take on some additional stages in the production process for their society news.

Key items they would need: algorithmic pre-editing with reference validation, XML conversion, and then staging the content on their publishing platform. And then doing a quality control check after that. So on the next slide, so this is their current workflow, what they’re trying to simplify. So a quick walkthrough, you know, society staff gets the manuscript, goes offshore for a algorithmic pre-edit, comes back to society staff, then they send it to us at J&J for the copy edit, we send it back to the society, who then sends it back offshore for XML conversion and then some combination of vendor, plus staff, plus I think freelancers even, then stages the content on their publishing site and then they QC it and publish. So a little complicated, I mean it’s not outlandish by scholarly publishing standards, but you know, if you’re trying to get all this done in the span of a day or two, like that’s kind of a lot. And it’s definitely a heavy burden on society staff, which is compounded by the fact that the spikes of content come in when society staff bandwidth is at its most compressed. So again, around the annual meeting. So overall this customer’s really trying to optimize for speed and low staff burden if they can. And, thanks to our relationship with Inera, J&J can offer just that.

So, the workflow we proposed for them looks a little more like this. So content comes in to society staff as before. Society sends it to J&J, where we use eXtyles to do the pre-edit, then we do our copy edit, then we convert the content to XML. Stage it on their publishing site, and run a QC checklist against the content. And then, theoretically, all the society staff would really need to do at this point, is click publish and we can do this all in a day or two, depending on what time of day the content comes in. Obviously, this is going to relieve a lot of burden on the society staff, eliminate the need for multiple vendors, and they don’t even need a separate contract with Inera as we’re rolling this all into one agreement with J&J, cause we’re going to manage the eXtyles implementation on their behalf.

We’re really hopeful this project materializes, because I think it exemplifies like the strengths of both J&J and Inera, and can hopefully lay the groundwork for sort of a, an interesting workflow model going forward. So, I obviously don’t have to convince this audience of the value of, of having the production process close to home. And I think there’s a lot of publishers out there, who have, you know, complex workflows that might not be serving their needs as well as they’d like. We’re, we’re definitely hoping to offer them a new option with eXtyles Plus, and this J&J Editorial partnership with Inera. I feel like we’re offering something a little new here, a little different, sort of a new level of editing quality mixed with speed and it’s all available at scale. So we’re, really looking forward to see where this goes. And with that, thank you. we’ll take questions.

Liz: Thank you very much all of you. Yeah, if anyone has any questions, either in the chat or feel free to unmute your microphone and chime in. I just wanted to, kind of, reiterate something that you all alluded to, which is that it’s interesting because the relationship formally is with J&J, and that does simplify things for the customer. Like you say, they don’t have to have a separate arrangement with us, but we have been working with you and the customer collaboratively, because we are all colleagues, and I think that not only facilitates the process, but I think adds that extra level of quality control and high touch to what these customers are getting. So hopefully you all have felt that that’s been a good way of moving forward with these types of projects.

Michael: Oh absolutely, yeah. No it’s great. I mean Liz and I have like a monthly call where we just talk about all these kinds of things and yeah, we’ve, we’ve definitely found that we really like the Inera people. Like I don’t know how else to say it. Like we just, we’ve really enjoyed getting to work with them and getting to know them. Cause it seems like we’re just on the same wavelength. They just come from the technology side. We come from like the people services side and we’re kind of meeting in this.

Liz: But we speak the same language for the most part. So that’s been very good.

Michael: Yeah. It helps that you used to be a copy editor. I think so.

Liz: That’s, that’s, many of us used to be copy editors, so it’s in, it’s in our blood. And I will point out that Ulysses said from Jasmine your screenshot, there’s nothing quite like the sight of a fully eXtyles-processed reference list. And I have to say, it’s been so long I’ve been working with eXtyles-processed reference lists for over 20 years, and I agree, I still get excited when I see a , a fully processed one is such a beautiful thing.

Jasmine: I think we said, some of us said in our planning meetings that running eXtyles feels like it scratches your brain in a really satisfying way, or it does for me.

Liz: Oh, that’s great.

Jasmine: It’s enjoyable. So.

Liz: Any questions?

Michael: I’ll say my– like the only downside of this is like I don’t actually get to use eXtyles. Like, I just talk about it all the time, and then they get to use it. So, so.

Liz: We can give you eXtyles if you want.

Michael: Can you? Can I get like the free lessons?

Michael: Just to, to experience this.

Liz: Just if you want to run a reference list and get that satisfying brain scratch every once in a while.

Allegra: It’s like ASMR content, like look at this reference list now that it’s been reformatted. Look how organized it is.

Jo: I love Cindy’s comment

Liz: She tells everyone, yeah, that “eXtyles is my favorite logic puzzle.” But it does most of the puzzling for you, right Cindy? Ideally.

Cindy: It does, but sometimes there’s some puzzling involved in figuring out how to tag things exactly right. When you’ve got a separate complicated document or speaking personally, eXtyles builds, so.

Liz: Or like the sort of things Joni was talking about earlier.

Cindy: Right. Yeah.

Bruce: I’ll add actually one more comment, which is over the years Liz and I have definitely run into organizations that said, you know, we love eXtyles, but we don’t want to take on running it in house. And so now what we’ve really got, is the dream team combination, thanks to the Partner Solutions structure. It has Inera and J&J working together, where Inera has always taken the position, “We do not run the software on behalf of customers,” but we can partner with J&J. J&J can be the primary point of contact with the customer, so that J&J can run it. So, it really does fill a market need for people who wanted eXtyles, but just didn’t want to run it in house. And we’re really thrilled with that.

Michael: Definitely. Yeah and we’ve, I mean I’ve, you know, been aware of eXtyles for, for many years and I, I even like toyed with the thought of trying, you know, pre-acquisition, trying to, to build a relationship here, but we never quite had the right arrangement, right project to do it with. So, so this all kind of came together really well for me personally and

Liz: And quickly!

Michael: But also professionally and quickly, yes.

Liz: We’re, we’re pretty gratified by the fact that like I said, J&J has only been part of Wiley and Partner Solutions for a year at this point and we already have multiple customers that we’re working with on joint projects. So yeah, it’s been great.

Allegra: Michael, did you orchestrate this whole acquisition just so you can have an in with Inera?

Michael: I was trying to keep that a secret, but yes, I actually bought all of scholarly publishing, including Wiley, yeah. Yeah, that’s you know, secret though.

Liz: Okay, well it looks like we’re at right about at time.