Attendees: Paul, Joe, Heather, Alice, Nevil, Julian, Tony, Robert
Absent: Adam, Ted, Dave
Heather to send out a poll after the next agenda update so that the design team can meet. Joe is tentative for July 10
1. Status of existing drafts
So far, only small editorial improvements, and that is already in the -09 draft. Some of those applied to the v3 draft, and Paul added that to his draft as well. Now waiting for the second review to come in.
Paul has a stack of small to medium sized things to put in. Some will be impacted by conversations today or on the list. A significant rev is scheduled for next week. Some of the bigger ones (e.g., are we going to have a micro format for particular kinds of tables?) should be discussed in Toronto.
Joe is willing to back to back off of the strong stance on Julian is a metadata junkie, and likes having as much in the HTML, so let’s back off on ALL. So, what additional information do we want in the HTML for which there are customers (e.g., search engines). Joe is ok with that for now, but if we decide some day that the HTML is more important than the XML, we need to revisit this decision. (ALL AGREED)
(Paul) the semantics we currently have for ‘id=‘ will help with this quite a bit. (Joe) we could also use classes; the less that we polite the name space in IDs with semantics will be helpful.
(Paul) Like using id’s for single sections that we know what they are - any objection? (Julian) copyright or TOC are examples should have id’s instead of classes because you want to be able to link to them. We need to know how to reserve the names we want to auto generate so there are no collisions. We can do that with a prefix, a white list, something. (Paul) Now, we’re going to call TOC and copyright, and those are going to be the same as author-generated id’s, so the processor will have to check that the author isn’t using them themselves. (Joe) we just need to make sure this is in the tools to check.
(Paul) this will make things easier in the XML draft, and make the the HTML auto generated id’s for: section, figure, paragraph (numbered within a section)
(Joe) prefer prefix to blacklist or whitelist; search engines will still find something like prefix-copyright.
(Paul) prefix shouldn’t be “rfc-” or “id-” or “x-”, but it could be “-“; (Julian) the anchor syntax in HTML is probably relaxed, but a fragment identifier probably needs to start with a letter
The advantage here is that people who haven’t seen this RFC can still index into it in relevant places. That’s why the auto-linking that the rfc markup script that generates the current markup script, because it knows what the target will be.
Paul will need to add auto generating paragraph to the xml2rfc v3 draft; (Julian) adding paragraph will be a bit of an exercise to figure out tables and figures; a complete list will still be a paragraph when it is not a top level. When a list is a child lament of a section…
Section 2 starts with a heading, then a whole paragraph, then a free standing list, then a paragraph. What should the list number be? 2? (Julian) yes. (Paul) anything that can be a top level item in a section needs to have auto-generated “foo” and they will all be the same that gets reset for every section. (Julian) it is a matter of taste. If a list is text, it could anchor as a paragraph, but if it is figures, it could anchor as a figure. Paul will start with everything in a section have the same numbering scheme. (Julian) since tables and figures may already have labels, they can have their own numbering. Paragraph (1), list(2), figure(1), paragraph(3). Figures will have a global counter.
(AOB) 2119 markup
In HTML this will turn into <span class = bcp 14>
2. Remaining drafts to be created
Julian and Paul haven’t start on this, and probably won’t have it this week. May have a -00 when the window opens in Toronto. (Robert) would you be willing to set aside a time during IETF week to have at least a set of examples by the end of the meeting? (Julian) will be there until Saturday, so should have free time after Tuesday.
Remember Tony has a fairly complete conversion tool drafted. Perhaps we should run this against the existing pile of AUTH48 XML drafts? Julian has the large pile of drafts that we could test against. Julian will send a zip file to Tony and Joe with the drafts.
3. IETF 90