 Thank you, Candice. Thank you, Candice. And I believe you'll be putting the URL of the handout out there too, right? So all right, let's get underway then. This is a follow-on, whether or not, from what I did a month or two ago, which was the general idea of writing a formal spec. But this is where the target audience is particularly ISO for publication. And so the handout is extensive, and the set of slides is taken directly from that handout, and so we'll just pick out some of the salient points. So just to get some terminology straight, we have ISO, the International Standards Organization, which we're talking about today. We have the Electrotechnical Commission, and then we have them together where they actually publish joint standards, and then they actually have a joint technical committee called JDC-1. And so it can be a little bit confusing with the acronyms, but JDC-1 is where many, not all, but most of the IT-related standards we know out there are available, but some are ISO standards, some are IEC standards, some are joint. The thing is is that the publication arm for all of these groups is the ISO Central Secretariat. So when we say we have an ISO standard and we have requirements for publication, we mean the rules as set down by the ISO Secretariat, which is in fact charged with editing and publishing or getting ready for publication. Now the most important thing here, which it may be changing. There have been threats over the years, but essentially, unless you have an exemption, whatever that may mean, submissions need to be in Microsoft Word, preferably using a particular template. So if you're listening in today, then either you're committed to go down the ISO publishing route or you're seriously considering it, but I'm going to raise some questions and potential red flags through today that might make you question that or to try to find other answers, which I am not able to give you, on the suitability of doing that based on the process and some other requirements. But certainly requiring something to be in Word, if that is not your current medium for developing things and you've got existing large and non-trivial complexity of a specification, that definitely is a consideration we'll be revisiting throughout today. Now the handout itself is actually written using the basic simple template that ISO provides. It's one of a number of things, but I figured it makes sense to present to you a document that actually uses the requirements in terms of the standards for better or for worse. And so keep that in mind as you're actually looking at the handout itself. Now there are two governing documents and that control what is allowed or required or allowed inside of a formal ISO spec. The first is ISO IC Directives Part 2 and there's a URL for that in the handout. That's 100 pages long, at least the one I looked at this morning. In the last year or two, they've also chosen to finally publish their style guide, which are certainly most important because it previously was not public and so it was hard to comply with something when you didn't know what it was and you've got different conflicting answers. So that's about 40 odd pages. So to think about it, OK, I'm going to write according to some rules, but I've got 140 pages of rules, makes it a fairly foreboding sort of a task there. There's a lot of detail there and complexities and various kinds of things and it can be hard to find something as a late person coming in at the light end and over 30 something years of trying to understand these things, I've distilled a bunch of very important things in the handout, which I'll cover in this presentation. So when you have such a comprehensive set of style guides and you have a committee, a standing committee, charged with maintaining that, you have some sort of a bureaucracy involved there as well. Now, the table of contents, we'll just scroll down here. My intent is to go through it serially, touching on sort of the important bits in each of these categories. And then section eight is in fact where lots of the nuts and bolts are for the specific editorial issues. And then nine, which talks about some of the downsides of things. And so we'll spend most of our time getting up to that eight, but then we'll touch on some important aspects there for you to think more about the implications. So again, if you don't have a spec written, that's an OK position to be in because you don't have to go and undo anything or redo. But if you've got something written and if it's substantial and complex and uses styles or other things, or if indeed it's being developed outside of word, then a lot of these things will have some non-trivial impact on that whole process and may well adversely affect the decision about is this the route you want to go. So let's then kick off with just some introduction. So the publications we're talking about fall into two categories. They are standards or their technical reports or TRs. A standard is a normative thing that is used to compliance and validation and testing and procurement and these kinds of things. A technical report, there are a couple of flames of them, but those are information that's, by the way, here's some interesting things. Here's a study, here's some background statistics, these kinds of things. It could contain a test version of something. We are thinking about making this major breaking change to an existing standard. We'd like to float it out there to the public to get some feedback. So it's not a requirement, but it could have a variety of purposes out there. So you should know about that because the rules for writing one of those are essentially the same as for a standard. And when you're doing a multi-part standard, some of the parts could be standards and some of them could be technical reports or they could all be standards or all technical reports. So keep that in mind in terms of the organization. Now these are required to have the layout as specified. And if you're a past submitter, which I think if you attended on Tuesday when Seth spoke, you'll know more about that, you typically have some latitude with the first edition. We are bringing a spec in from another organization that has previously published it, but typically long-term you're expected for each new edition to then start to comply with these particular set of rules. And the most important thing here to understand is the model that ISO uses is the printed page. Ultimately, when the dust is settled, you've got a PDF that will be published by them. And so the world to them looks like a printed page, which is not how it looks for many of us in our general usage and certainly for documentation and things like that. And so when you're dealing with things like developing documentation in GitHub and various other tools, then how does one get it into a paginated form and what are the implications of that? So a year ago, I worked on a project through Linux Foundation that in fact is a website and that's how they have it. That's how they wanna keep it and that's how they want their standard version to appear. So clearly that's not a suitable candidate for submission to ISO because it's not gonna be in the form of a paginated document. So then the purpose of the document and this presentation today is to give you practical information about the compliance issues in particular here and to point out some of the things that you need to pay particular attention to. All right, so that's the end of just a general introduction. Do we have any general questions there for me? Nothing in the chat, Rex. Thank you. All right, now it's important to understand the process that they use because it has changed in recent years. It used to be entirely people-based. You sent stuff to them by email or uploaded to a website. They manually went through and did things and they could cut you a lot of slack because there wasn't any software monitoring and blocking any particular current construct. So if something got through that didn't comply to the rules and nobody noticed, well it got through. That is now not so much the case. They have some sort of a suite of tools which involves conversion to XML and I've never seen any document. They don't seem to be sharing what that process involves. And then the generation of that XML back to PDF for publication and they finish up with a new Word document. So they start with the Word document you submit. It goes off into some other world and then comes back as a newly reformatted Word document with white space, various all kinds of things are manipulated around there and it's doing an extensive amount of checking and potentially rejecting certain constructs and things that it discovers that either outside of the rules or their features in Word, for example, that they do not support such as tables within tables and we'll talk about a little bit later. And also, ISO editors might manually make formatting changes to this throughout the process. So you basically push it in one end and it's not until it comes out the other end that you have some chance of getting feedback. And so at that point, so the important aspect there, I am not aware of any facility online, a testbed where you as a prospective submitter could go and grab a draft copy of your spec and no matter how small it is, push it through the tool process and get back the feedback to say, how am I doing? Am I using constructs that I haven't learned and not allowed or some other kinds of things? That would be a very valuable tool and seems to be ought to exist out there but I've not heard of such a thing and we'll talk later about how you won't find out what's rejected until way into the process. So when you finally get back from ISO, a draft spec for proofing, then you need to actually go through that Word document and do a diff with the one that you submitted. Every time I've done that, I found errors that were introduced either in content by naive editing changes at ISO or formatting where their tool has taken something very technically important and has reformatted it and that's unacceptable for the spec. And so you definitely need to know what that tool is, you need to look at it and compare it mechanically certainly for non-trivial size and complex documents. The ISO editors are unlikely to be subject matter experts in your field. In an hour ago, they were doing an undersea welding standard and in two hours they'll be doing carbon footbridge standards for airlines and in between they've got a standard for a computer programming language. So basically when you're communicating with them, you have to come up with abstractions and try to explain without getting into the particular technicalities of your subject matter area. Now, once you submit and you get into the ballot process called a draft international standard ballot, you'll get comments back, which you may have to make changes to fix to get or keep a majority of that. And that is an iterative process. And so that all happens before you submit anything to ISO. So you are basically right down to the end of the process when you actually submit your first or a new addition to ISO before they get involved, run it through their tools and give you that kind of feedback. You don't have a mechanism easily up front to say, hey, where can I send comments or can I talk to other users like myself? It seems to me that ISO should definitely have a website and some kind of a chat room or facility where at the very least people can exchange information and they can provide answers to things that you can look at over time when you're trying to figure out some particular aspect of things. And so I have not seen any of that available. So it's rather an interesting process where there are a lot of rules, the implications of which you don't necessarily understand until very late in the stage. So this is now you can see very large print here because this is I think a very stunning slash shocking comment. So the ISO editor assigned your project is unlikely to have ever been on a committee that actually produced a specification as such they haven't experienced the process from the other side that is from outside where we're developing it. When I attended a project editor's conference 10 or 12 years ago in Geneva and I was there as a representative as an editor of a four part standard totaling 6,500 pages, clearly a very large and unusual thing. And when I said what was the average length of an ISO standard and they thought for a bit and they sent around 50 pages. So as you can imagine, managing a much larger and complex specification can require a greater understanding of the real world issues resulting from size and complexity. So most of the work I've done in standards has been computer programming languages and platforms with large libraries and easily start at 5,600 pages and go into the thousands. And that's certainly a lot of the work of ISO, IEC, JVC-1, which is all the IT specs and security and other kinds of things. And so if ISO comes back to you and says, oh, I'm sorry, you haven't got the right format for your section headings, you need to change those. If you've got a 50, 10, 20, 50 page standard, sure, in an hour you could do that. But when you've got hundreds and thousands of pages and literally hundreds and thousands of section headings, that is not a trivial task to do. So that's what I mean about their rules are written around this whole experience of managing small documents. And so I can assure you that the frustration rate for me personally is very high as a result of that dealing with large and complex documents. And so that's simply about the actual, the test bed and the environment they have that they now use. And by the way, it can't handle documents beyond a certain unknown size and complexity, including the 6,500 page one I mentioned. And when I was retired from that project, they still hadn't decided how they were gonna deal with it, even though they've dealt with it manually for a three or four editions previously. Right, any questions on number two? No questions in the chat, Riggs. All right, so now what comes out of the ISO process is a Word document. And while they almost certainly intend that's what you use as the basis for the next one, that is not a requirement. And there are reasons I'll point out why that is in fact undesirable or in fact quite impossible. Firstly, there are good reasons why editors choose a particular document management tool over another. I know for a fact there are corporations and industries out there who said they will use Word over their dead bodies, end of story. It's not allowed in the tool chain. There are plenty of people who are now moving towards collaborative editing through things like GitHub with Markdown. And that's where all of my work has been moved in recent years. And so then you have this interesting issue that yes, ISO gives me back a document which they're then gonna distill the PDF and publish. But now I have to go through and figure out what all the changes were and reapply it to my non-Word master base copy. So if you wish to continue using a non-Word platform you have to determine all the changes that were made by ISO to the submitted spec and then apply them to your own base. And then of course you'll convert at some later point again. And so the point out too that error is that we're somewhat introduced or not handled properly during that final distillation phase. So the lesson here is that the document you get back from ISO while that certainly will serve as them to use for publication might not be suitable for use as the base of your next addition. And you need to understand the implications of that. Quite, it's a very strong thing to state and to note. Right, questions, anything on that? Right, so then, all right, now let's get some terminology down. So a chapter, so if you've got a standard it's typically at least more than one chapter because you're required to have a scope at terms and definitions and some other entries. Each of those things is called a clause. So you think of that as a book chapter. What's below that at the next level is a sub clause like 1.2, 3.5 and then some clauses can nest. So 1.2.3.4.5, et cetera. And you again have to think about the number of levels that you wanna use for a large and complex document I've had up to six levels. That will have direct impact on things like the table of contents. For example, the 4,500 page part of my ISO standard I used to edit, when all the levels were switched on generated a table of contents of a hundred pages which is twice the size of most ISO standards. So clearly that's interesting and fairly shocking to the ISO editors to think about documents that large and complex. Yet if you are forced for whatever reason to reduce the level of entries in the table of contents say to three then how can you actually get to the rest of the entries without browsing down through a large document? And so I'm jumping ahead a little here but the fact is word allows you to put table of contents all throughout the document. So you could have top level table of contents at three levels and in the third level entries you can have table of contents for the fourth and fifth and sixth levels. I have never gotten an answer from ISO whether their tool will recognize or allow nested table of contents but based on my experience with the things they don't allow I doubt very much they do. So you need to know about that in advance when you're structuring your document. Is it a one big document? Are there multiple documents? Breaking it into multiple documents gives you the problem is there's no way to do inter document links and have them be correlated automatically. All kinds of interesting issues there. Now an appendix something that started to be led at ABC coming after all of the clauses is an annex and annexes can have some clauses. So A.1, A.1.2.3. And then the other important term here is that there are two kinds of content. There is normative content. We spoke about that in my first webinar that is the things that have the word shall and shall not and how does one tell whether one has conformed to it? How could I write a test suite? How could somebody look at my product and description and check the boxes for procurement? And then there are things that are not normative which are either called non-normative or informative and that's important because they have to be typeset differently and that's a whole interesting world of itself if you're coming safe and get up which doesn't have that distinction. So then any questions on terminology? All right, now, so how does one get into the first version of the spec assuming that we don't have an exemption and we're going to make it work? Well, as I said, if you're starting from scratch well, you grab one of the templates and you start dropping in the text, all right? So that's the cleanest and simplest. You've got an existing specification in Word but it does not use the template and you use that. Of course, there'll be glitches because of styles and things but that would be your starting point. You might have an existing specification in some other format and you can copy and paste blocks of text into the word template that you start with and apply its styles and clearly that may work for a bulk of it depending on how smart the copy-paste mechanism is on your source format as to whether preserves things like bold and things that Talix varies other kinds of formatting that you particularly want. Well, finally, you can actually have an existing spec in some non-word format and programmatically generate the Word document to try to preserve as many as possible of the attributes and one way is through Pandoc. So if you're not familiar with that I've used Pandoc to convert from Markdown and GitHub to Word for the purposes of submission to ISO and I've written about that privately at least in reports to my clients about how good a job it can do and there definitely were issues in dealing with styles in there. So, and I just in the last couple of days Jory and I've learned about a whole new open source project out there that apparently is quite large and active which I've never heard of before called MetaNorma. So maybe Jory if you're available you could drop that something a link to that. There's certainly a website MetaNorma and there's a GitHub open source site for that. And they actually claim to be a major supporter of developing stuff outside of Word but to make it go to Word in ISO. So, while some flexibility appears to be allowed you won't know for certain until you try and get back from ISO approved after it's been submitted and that's just to reinforce what we said earlier that it would be nice to know if you're running off the rails as early as possible in the process but if you've got a non-trivial spec of hundreds or more pages and to find out at the very last bit that you have to go back and do major surgery that certainly is where's the budget and the time and at that point the technical people on the project are tired of proofing it and so there's all kinds of interesting issues there. So, I don't think we need to pause there for any questions. So then, let's take a look at some of the ISO requirements. So, having used Word for many, many years I fell in love with soft returns which inhibit basically bad line or bad page breaks and things and there are places where they are really necessary as in item two here but the fact is they're tooling does not appear to preserve them and so this is one reason why what comes out the other end is not necessarily useful as a starting document even if you wish to continue maintaining the spec in Word. So, understand about soft returns and how useful they can be. In fact, you need to know how to use them to write an annex because you have to have a multi-line header for annexes unlike clauses which says about whether it's normative or not along with the title and you have to make that a single physical line that actually is split over two display lines and the only way to do that is with a soft return and so there's a little homework for you. The terms and definitions clause and we'll may see some of those later also require this because you have a term like 1.3 followed by a bolded term followed by a description and from a pagination point of view you want all of those three lines to be on the same page not to basically break across bad page breaks but it's not entirely clear to me that after the ISO tools run on it they can guarantee that if they're not preserving this. So, even their published PDF might not look so pleasing from a publishing point of view and so if they tell you well, we're going to insert hard new page things in there that's a red flag because that's definitely, that's using a typewriter not a word processor and that's basically something else and if they do that you have to remove those from the final word because you don't want them there for your own things as pagination will change. Styles, right so in theory, they want that all the terms and definitions to be spelled out up front well, that's fine for 20, 30 page document it's not fine for a 500 page document where you've got 20 or 50 core terms and then you've got in each of the major some divisions on your spec you've got 50 or 100 terms you would like to introduce them as you go there's no way to do that and the very standard way of English publishing of doing that is to italicize the first usage of the term in such conditions is not in fact permitted and we'll talk more about the fact how ISO has a bunch of rules that when you're publishing in English do not actually comply with English publication standards as used in the UK and the British Commonwealth and that to me is just a major disconnect. So right justification the spec is required to be right justified and I've got an example taken directly out of the spec that shows you what it will look like and you said, oh my God, that's nasty and so they do allow you to override that in certain cases but the thing is what does their tool do and who's going in there to modify it after their tool has run to get rid of the really nasty looking ones and five is you can refer to the handout for that. So another reason why I certainly cannot use the output they produce as the base is that I make a great deal of use of cross-reference links. So again, even in a 10 or 20 page standard you probably say in section three, oh, C4.2 in parentheses or you have a back reference somewhere else and you can use these extensively and obviously when you've got a large document you should use them regularly so that people don't have to remember or have to manually go back and find why not let them just say, hey, click on the link and go read what you are referring to and then come back. Unfortunately, well in word when you do those things they actually are set up behind the scenes in a special manner that makes it all relative so that when you change the document and you add a new clause or you remove a clause or some clause everything all the numbering of these references is automatically readjusted as it should be and as a word processing person would expect. Unfortunately, the word produced that comes out at the end this is all stripped out and the references are hard coded. So where you previously said, I wanna go to 1.3.6 and that could or to later on be automatically changed when the spec was enlarged or contracted that's now hard coded, that's simply unacceptable and you cannot use that as a base because you reserve the right to add or remove sections and sub clauses and clauses. And over any realistic living spec, that'll happen. They removed pairs of spaces things and but they do preserve non-breaking spaces here which is very important to use as a long-time editor and publisher I'm a big fan of non-breaking spaces if you don't know what they are or you're not using them you should that's a top priority as to why you want to start using them. Okay, people will read more of a document that's pleasant to read and non-breaking spaces helps that. Okay, questions at all on that? None yet, Rex. All right, good, conformance. Right, so one, you don't need to have a clause called this although I talked about it in the previous webinar for non-trivial ones you might very well want to have it that is how is this spec to be interpreted in terms of conformance? This will spell out the rules and so it indicates the requirements, the recommendations of permission. ISO certainly has specific words you must use such as should, must, can, may and the negative version thereof and they all have to be written in lower case unlike some of the ITF aspects that are widely used out there. So again, if you're using one of those you'll have to convert them all to the ISO format and in doing so they'll no longer be uppercase which makes them harder to search for and find they'll just be regular English words. So that makes it a challenge. So we talked about normative and informative stuff by definition, notes, examples and footnotes among other things are informative and have separate rules by requirement which we'll talk about. That of course doesn't have to be spelled out because it's in the ISO style guide but again, you might have some information about this as to explain your format and layout as to how you're using these particular things. For example, the ISO format suggests that your notes and examples are stand alone. You might very well want to have them as sentences in existing paragraphs and that can cause you interesting brief because that doesn't comply with the ISO standard. It forces you to separate them rather than just having an aside comment in the middle of a paragraph which says an example or a note you have to then rearrange things. And then the whole annex needs to be identified to be the whole thing is normative or informative. And so it's interesting is that you can't have well, it doesn't appear that you can have mixed things in an annex. So as I said, it's useful to have a conformance clause and you might also have conditionally normative information. For example, I've worked in a lot of programming language and computer operating system specs and one of the ways of representing floating point arithmetic in hardware or at least in software is what's called an IEEE standard which is also has an IEC equivalent. But so if you read the specification for the C programming language, it says, well, you can support other formats, but here's an annex that is normative that says, if you choose to use this particular approach, then here is what you have to do. That is it's conditionally normative. You can comply to the standard and then you say within that whether you comply to the optional bits within that. That's not very common in standards, but certainly I've made great use of that in my code. So here's another interesting thing to consider. If you've got a large and a complex specification, it might be useful to have an informative annex that contains a summary of all of the conformance rules. So here I am, I wanna build a widget that complies to your spec and it's 100 pages. And I said, well, I can read it through and I can get a highlighter and I can say, well, okay, here's all the shalls and the shall not to whatever, but wouldn't it really be nice if you had an annex at the end that said and called those out so I can see it at glance, even by clause or some clause, all of those things and things that are related. A very useful thing to have, but to extract that, you would need some kind of a smart program tool to find the appropriate characters. And as I said, they're gonna be in regular lowercase English, they won't stand out, there will be no special hooks to find them. So you have to think about how to actually do that and maybe with special tags or some other things in there that maybe removed later on from an ISO point of view. Well, it also has a way to have hidden information, but the question there is, do their tools remove that and render it not useful? Right, so anything on conformance? All right, so now let's get into some of the nuts and bolts. So first of all, we've got some general things here but this now is clause eight and we'll see over the page, there's an eight dot one and an eight one one. And so the big issue here is there is text between eight and eight dot one. There is no text between eight one and eight one one. A careful reading of the ISO rules says you cannot have hanging paragraphs. That is, you cannot have text between two different levels of headings. That is not that, other than if it is in part of its own header. So this turns out to be a very common thing that people do but it forces you to start to create a new sub clause right from the very beginning of each clause which is artificial for many people, including myself. But nonetheless, that's called a hanging paragraph and that is not permitted. They tool almost certainly will flag that. If you then have to go back to fix it and you introduce a new heading in front of this which will be eight dot one, obviously that changes all the numbers and that point on but hopefully that's all automated and so nothing breaks at that point if you do it properly. And so beware of hanging paragraphs. Now the rationale for that is that if you have a reference somewhere in your document that points to eight, is that pointing to eight as a whole clause or is that pointing to the preamble at the beginning of eight before eight dot one? It's obviously ambiguous and that is a rationale. And I don't have a problem with that. It's just I very rarely have references to that worry about that kind of level of detail. So that's hanging paragraphs, not permitted. So clause number format, nothing big deal there. You can read about it in the handout. Now, an important one for me at least in my history is that I have not found this in the directives or in the style guideline but I've been repeatedly told over the years and is a requirement. So the lesson there is there are rules that are not written down or made publicly available and you might find out about them for the first time when you get your spec back from proofing or in the early stages. The one that I learned about is that clause of some clauses at all levels must use sentence case. That is only the leading letter or letters in proper nouns and names can be uppercase. So for example, I've got a spec that has a section that I would like to call mapping zip item names to logical item names. I must instead change that with the uppercase M. I keep the casing of the zip since that's the spelling of that particular tool but I must remove the leading upcase and item names, logical item names there. And so when I was told to do that, the editors clearly are thinking in terms of a 50 page ISO standard, not a multi-thousand page spec where this is a non-trivial effort and it's subjective because it's not a matter of writing a program to convert it automatically because it has to recognize exceptions to those particular rules. But even so for a non-trivial spec that can be a significant amount of busy work that absolutely does not improve the technical value of the spec. And so that's one of the things where I fault ISO in their complete lack of flexibility to allow styles widely used in US and British Commonwealth style English writing and publishing. And so again, can lead to frustration. So know these things in advance. Now, if you are doing anything that has computer programming, it might have XML fragments, there might be configuration files or configuring tools, any kind of a text that you sort of create an edit that is used to drive or configure or do something, a profile, all kinds of things, then you can send it in any font you like as long as it's Korean noon. And I say that tongue in cheek of course, a lot of people out there love Korean noon. A lot of people hate Korean noon, but you have no choice. That's what you have to deal with. It's certainly not what I use. I use Calibri, but they apparently is a Microsoft font and ISO one except proprietary fonts. So now let's look at some text that doesn't involve a block. So let's say in IT specs, you very often want to grab linguistic terms and display them as such using the constant width font. And so here we have an example. And you could also use that in non-IT standards as well where you wanna call out certain kinds of keywords or important kinds of terms. And so that's what it's gonna look like in using the Korea font. Now, and not Calibri console. So ordinarily, this author uses Consolus in his work. However, characters in new are wider than those in Consolus. So when I at the last minute change to Korea to get ready to submission to ISO, it turned out that certain blocks of code, in fact, were too wide. They were very long, but they became too wide because the extra width of that font. And therefore I had to go through and have a look at all of the examples and manually break them up across multiple lines as necessary to make that actually fit. So again, as I said, you don't get to choose the fonts. They choose the font for the normal irregular text and the font for the fixed width is Korea New. And you are extremely limited. I mean, that's your fonts, right? So all right, questions then about things to that point? Nothing yet. So actually, Rex, let me then ask you, would you have some recommendation for the participants to go ahead and make sure that their documents are already set with the appropriate fonts and sizes? Yes, absolutely. As soon as you learn about a requirement, you should incorporate that into your draft and be living with it. So you as the editor get the maximum exposure as do the reviewers, despite the fact they may grumble. It's like, no, that's not a negotiable issue. We have to do this. So if you're developing outside, then obviously that's not something to be considered there. Only during the transposition phase that you have to come back and deal with these things. But even then, say you're in Markdown, you could go in and say, well, we're really limited to 75 characters here in constant width font. So let's do that. And using Markdown, Lint and some of the other tools, you could enforce some of that as well. But definitely, there's the concept of dog fooding that you basically are forced to work with the limitations as soon as possible. Right, so they actually use Cambria, as I said, and those are the fonts, all right? And so their tool will normalize everything else to those. If you've got any other font used, it will quietly be converted to one of those two, and you won't be able to mechanically be able to search for it to see. You'll have to do the diffs, as I mentioned, to see if you inadvertently had others. And so for example, down here, I find it useful to be able to use italics versus slanted, but those are not supported. You have slanted, but you don't have the serif part of the Cambria typeface. They really suggest you limit your use of underlying bold and italics. I find those to be very useful at various cases. You have no shading or color or borders are allowed, very major things to highlight various kinds of examples and things. Of course, one of my specs involve very much color. And so clearly we had to allow color there and also involve shading in examples and figures and things. But again, I don't know what their tool is going to do with that since I didn't stick around long enough when the tool will start to be required. So giving emphasis, again, they have strict suggestions about not using that kind of approach, again, which I believe goes against the grain of standard English editing and publishing in the UK and the US. Right. OK, so now sometimes you want to provide links to things that are external only. There could be other resources that are normative that are required. You might have 100 page configuration files for various kinds of options and all kinds of things. And so ultimately, those need to be given to ISO, which will post on its own website, not on anybody else's. So therefore, any links in your document that reach them have to have the ISO generated link, not yours. So that's another touch up at the very end. It also means that you can update your own private copies over time as a consortium developing new versions, but that will never be reflected. And that's by design. ISO doesn't want anything to change out there, right? The standard points to a frozen set of things. Now, you should also ask them, are we required to also have a printed version of that text in respect? If you are, and I've had it both ways, I had, in fact, 600 pages of this, which was required that he pulled into the spec. So two things come out of it. Can you make links into that space from your main document? And if so, how? And how to get those preserved as links that people can randomly jump to. So you might have a schema as an attachment for an XML standard related spec and that that. Secondly, now you've got a version, inside the spec and you've got an electronic version. One of the two are not in sync, which wins which one is normative. And I've been there, done that, had to deal with it. So better to only have one source of truth. But if it's electronic only, not part of the spec, you can't typically have links into it because there we no support from that from a PDF, necessarily. So difficulties there versus having a web-based publication versus a paginated one. Right, so justification of text we talked about. Soft returns, we talked about, here's the example. So the challenge in the table in the terms and definitions is to get a good page break, you want these three things on the same page, but if they remove the soft returns, then there's no guarantee. So you go to all the trouble and then it's removed at the end anyway before publication. But the interesting challenge here, and I show you how to do this in there, but is that you have to number them in a special way, but these numbers, while they look like sub clause headings, are not allowed to appear in the table of contents. And that is non-trivial, especially for 90% of word users out there because they have no clue how to create a word field and a counter to actually make that work. And so that is a challenge off to it on its own. And again, if you've only got 10 entries, sure, these can be hard coded because when you add an 11th or you remove one or rearrange them, you're in half an hour's work, you can do that. But when this runs for pages and there's some complexity, you sure as heck don't wanna waste time going and manually doing anything. Also, what is not shown here is that if a term and definition refers to other terms and definitions, you're required to put a link in there or at least to state that. And I am not aware of an easy way to do that at all inside of word. And the fact that they don't produce non-trivial specs themselves, their tools and guidelines don't tell you how to because they've not figured out the how themselves as best as I can understand. So a set couple of fairly interesting issues here right up front with the terms and definitions. Okay, we're at the 10 minute mark. Let's leave time for questions and I'm happy to run long. Cross references, it doesn't say explicitly but it contains the following examples of how you do it. The most important thing when you refer to a top level clause, you have to say clause that. And this of course in between there ought to be a non-breaking space so they don't get split off the different lines or heaven forbid across page breaks. Likewise with an annex. However, when you come to some clauses, you do not say that you say 10.4, 10.5 or 8.1, blah, blah, blah, see whatever. The most important thing is, is that a very widespread practice in the UK and American English is to use the section prefix here. That is used to be that's a chapter of clause or a sub clause that is not permitted. I had to go out and remove every one of those which of course can be done automatically but it was again annoying because this is a worldwide acceptable for English publication of all kinds of things. So again, there's no reason for that. It's just that Geneva says so and you can't go past going without that. So then, okay. And entries in the bibliography have to have some number and then you can set up some reference to that. Again, I've ever only ever had very short bibliographies and mine have been hard coded with numbers but I think it would challenge you if you have a lot of these to set up some automated numbering systems for that to work. Again, they don't have this in their sample templates any support for that. Okay, we'll skip this one here. And then, all right. Now again, talking about non-English approaches when you write numbers in text and again, I haven't tested this of late through their tool but I can imagine you'll have tables full of numbers that involve a thousand separators that you are not permitted to use a comma, heaven forbid, as a thousand separator. And so I was totally stunned when I learned that. Now remember, ISOs in Switzerland and Swiss French does not use commas. Indeed, Europe doesn't use commas. The non-English speaking, they use periods but so that to me was I was totally stunned and I cannot find any reason for that. And for me, the complication was I had programming examples and the source code and fragments contained commas all over the place in numbers but also in the output produced, which has to be retained because that's precisely what the tool actually does if it's compliant, but then in the narrative you're not allowed to use the same format which is the contradiction. And I've raised this over the years with ISO editors but again, until they are forced to actually edit non-trivial specs themselves they will never appreciate these kinds of subtle requirements that they put on us. So all right, the front matter. Now, I will skip over that as well. You can read more about it. The table of contents we've talked about. You know what level they're tooling will allow and if you have more levels than how do you deal with that because they probably don't allow nested or having sub table of content scattered throughout the document. In fact, 99% of word users are probably not aware that's even possible. And they have some predefined styles, a word does but again, ISO, they publish no information about the style that they finally choose for that and which is allowed or disallowed. Their tool is gonna normalize stuff. Now, finally, if you have normative references to external dependencies that are not published as recognized standards and the most popular one I deal with is the zip file format you are required to actually get permission from the owner of that external thing through a thing and ISO mechanism called a referencing explanatory report. That is they have to be made aware that a standard out there and ISO standard is gonna be published that is pointing to them and then they give permission for that and then of course, you have to suggest well, could you please make it publicly available so it could be reachable for my users and could you also freeze it so that when our standard points to your 2021 version it's gonna be there forever. And so that's a whole new ball game of having to deal with some of the people writing specs that are de facto standards out there and it requires some maintenance because over time people forget about it and they stop supporting or publicly making available various old versions yet ISO specs are still pointing to them. All right. Right, so now all I wanna say about notes and examples there's plenty of things you can read about the bottom line is, is they are set in a smaller point size. So again, depending on how you're dealing do you have a style to do that? If that style is adopted, what is ISO gonna do with that? Are you gonna go through and hard code all those paragraphs throughout your whole document? What if you've got code examples inside of that? Will they also be at the same size? Yes, the Korean new and then if you're coming from GitHub or something else which has no concept of typefaces and styles then how do you deal with that? How do you market and get and recognize this as an example or a note and to deal with it? And so that again, you have to think long and hard about it because any standard worth of salt will have notes and examples to further explain what it is they're trying to convey. Lists again, there are some rules and restrictions there. Tables, we've talked a little bit about. The thing about tables and figures is they all have to be numbered. Everyone has to be numbered and of course, again, if it's hard coded that's a big job if you add and remove them and the rationale is that's so that anybody completely outside of your organization wants to refer to your standard and there's a table, they can refer to it by clause and sub clause and table number and a table must also have a caption and designation and not only that but you have to refer to it at least once in your own document. You can say the following table numbered A.3.4 with this is used. It's redundant that you have to say it because everything has to be referenced internally. So there's a lot of busy work here for the sake of a people out there who might actually use it whereas your audience might never use it directly. And so there's a summary of some things that they remove or don't handle well and we've talked about those as we went along. So all right, we're right up to the wire but I'm happy to have question time run long if there are questions to deal with. We haven't had many in the chat. So we'll just take a minute and see if anybody wants to utilize that Q&A tool or the chat to host and panelists to answer my basket question. Then just if you didn't attend the first webinar or haven't downloaded it, certainly do that. And I think you can easily maybe in the chat room point to where those are because a lot of the topics we covered today are covered in a general way and there's guidelines and for decision-making about which way to go and how to do various kinds of things. So if you're going to go the route of this webinar subject matter certainly make sure you have read and understood the first one as well since that will have a bunch of different questions having different purposes but feeding into this process. And Candice beat me to it with the link to the previous webinar that Rex did. I also wanna point out we've done a couple of different webinars that may be relevant to this audience. On Tuesday we had one on the publicly available specification process. We've had a webinar on antitrust and other concerns and we hope you'll stay tuned to the JDF project series because we'll be dropping a number of other hopefully very helpful trainings from folks like Rex in the future. Okay, is there something in the Q&A? Maybe not, maybe just, okay. That says about the expert, did you see that? Yep, what percent of ISO standards are written by an expert? Well, okay. Well, I have been the editor on specs where I am not a subject matter in it but that was essentially because they were so large and complex that you couldn't get your hands around the whole thing and still have a life. So I also work on projects for Linux Foundation for specs that I'm not a subject matter expert. I'm not writing the text but I'm editing it and I'm working on the structure and organization. And so most projects I expect there's a single editor and maybe they're not even doing collaborative work. And so it falls to one person who very likely is first and foremost a subject matter expert but not an editor or I'm certainly new to the formatting requirements of ISO. So I think you would have to have quite some experience under your belt of being in that role before you could claim to understand both of them in a reasonable fashion to try to notice when things happen. So when I'm editing a collaborative document and the committee adopts five pages of new text, I have to read it to make sure that it complies with the musts and the shells and various things. And in the case of notes and examples would have to deal with the point size being reduced. So the average participant on a standards committee isn't interested in all of those details. They're there as subject matter experts. And so the editor has an interesting job there of trying to deal and to detect all of those issues often after the fact that they've been in the spec. So they might have even been in there in the previous edition and have only just been discovered in a large and complex spec. So not an easy question to answer but because the word professional sort of has connotation to it. What does that mean? Here's another one. Another one, if the standard is complex how does ISO deal with the tech evaluations? Well, in my experience, as I said today you don't know until you've actually submitted it which is nearly the end of your process as to what they're tooling or even their editors. So you can't contact an ISO editor on day one of your project and ask for help because they don't wanna hear from you and they can't afford to hear from you until the very last stage because that busy processing things that are in the pipeline getting ready for publication. So you really don't have access to them or their tools until the very end of the process which is precisely the wrong time to learn these things when you've gone down the wrong path. And so that's why it would be very useful to have some sort of a public forum. Years ago, I tried to create an email exchange forum and that was squashed immediately by the powers that be in JTC One with some cooperation from ISO. Like how did those editors collaborate to find our back and start to solve things on their own? It was a very silly situation and I've not seen anything better than that. Okay, IEEE is an international consortium like OASIS and Ekron and National and others and it's a standard development organization that publishes its own standards. Sometimes standards are co-published by others. So for example, the floating point hardware forum that I talked about earlier for IEEE was then submitted by IEEE to ISO where it's also, it's to IEC where it's adopted as an IEC standard. Other groups publish things that become ISO standards but when they co-publish them then they have numbers in both realms that are freely available from the original submitter like IEEE yet ISO will charge for them if you go to the ISO website for those documents. And then maintenance is the term, where is maintenance? Is it gonna be done under ISO or IEEE? In almost all cases, it's done by the submitting organization. And so you have the concept of co-publications and while the world still talks about IEEE floating point, the formal specification is an IEC 559 yet and we have to use that in standards bibliographies and normative references yet most of the world doesn't know what that is. So ECMA International is another SDO that does its own thing and publishes and ECMA and IEEE are both category A liaisons to JTC1 which means that they can submit their standards as though they were a country member, a national body member of JTC1 and they come in at the top level of submission and that is they do not develop the specs within the ISO realm that develop outside in these consortia and through their own rules and they've brought in the very last minute and then they get processed but they still ultimately have to comply with the ISO formatting guidelines. I suspect the complicated relationships between all of these SDOs and how ISO actually works for my governance and decision-making standpoint is the topic of another very long webinar but we did just get a thanks. Thanks, Alfred, for the great questions actually. Let me see if there's any other questions from the group. Nope, got nothing. So I think we're wrapped up for today. All right, well thank you all for your attention and do read my email address is at the top of the hand out there should you have any constructive criticism or questions to ping me there. Thank you so much Rex and Jory for your time today and thank you everyone for joining us. Just a quick reminder, this recording will be up on the Linux Foundation's YouTube page later today. We hope you join us for future webinars. Have a wonderful day. Thanks all.