Attendees: Adam Alice Dave Joe Julian Nevil Paul Robert Tony
2. Do we have sufficient requirements for: Turning this in to requirements, we might be very close on that at least; for example, on SVG, we aren't close on knowing the profiles, but the set of requirements that says “if someone hands us SVG it must not violate a known list of rules”
It would be useful if we knew who the audience for the requirements - this not a strong tutorial, but you need to have enough information to reasonably evaluate what someone who would be building something would build, or how existing tools could be used
Goal is to have something we would be ready to announce what we're wanting to announce
For XML, what we need is a statement that we will start with what we have and will collect the set of things that we would like the things that XML would extend to in the future; Alice, Julian and Joe to write on that mid-term future; probably need to figure out what we're pointing at for now might be useful * exclusively referring to the XML vocabulary - the existing DTD; so what is the canonical document? it would be great if we could get the marshal rose RFC to be brought up to date; Julian was planning on doing this first Julian will produce something very technical explaining the vocabulary and adding to it as needed (the 2629 vocabulary, the xml2rfc as spoken today with it's 10 years of extensions, and what we want to do in the future) will document xml2rfc language as it processed today; will produce a template that's generated from the DTD, then have a system that can document the DTD; will try to have the tool chain and specification (with explanations missing) and then we can collaborate to have the explanations; easiest for him to use the existing xml2rfc repository; eventually obsoleting rfc 2629
we know what we have right now is not entirely sufficient for references, for example
No idea where we are in XML and HTML; PDF we are close simply because it will be based on some other things; EPUB is correct, depending on the HTML, TXT will be open, SVG will possibly the hardest one but probably the least important one to have completely finished (does NOT include these tags, but looks ok against the following criteria)
the XML profile will drive the HTML
Robert has not started
a. HTML (probably not) - Nothing documented on the wiki
Joe will start populating requirements language from his earlier doc and post on the wiki Tools Team expecting prototypical, sample output so we know where the strong design decisions are Need to come up with a way to describe the HTML such that a style sheet could be applied to it;
the internal CSS to the HTML is an area of interest for Paul
we've got two issues - what the HTML should look like, and what the HTML *is*, and we'll need some text around requirements for that; Joe is more interested in the latter, Paul may be more interested in the former Ted is interested in what the divs look like and the classes associated with those divs; need to figure out how to phrase that in requirements language as opposed to implementation language
expect to be able to round trip by using Microformats; might need RDFA instead - Julian and Joe to poke at this idea
b. PDF (maybe) - see https://www.rfc-editor.org/rse/wiki/doku.php?id=design:formats Note: I disagree with the need for the second PDF format, one having links but not having art or text formatting
c. EPUB (how different does this need to be from HTML?) Note: if we do tie this tightly to the HTML version, does that drive us to require a particular version of HTML (HTML5)? How does the EPUB metadata differ from HTML? do we need to create a profile to restrict the media types
The ToC lives in a separate file, the boilerplate lives in a separate file, but that's about it; Julian has scripts that generate these files directly from the xml2rfc source, so it is just one transformation away and the code exists; we don't need to pu t that in the requirements what type of metadata needs to be present, what does the layout need to be, are level 1 headings automatically indexed? Should references be bare text or links? One requirement is to use EPUB 3 (not EPUB 2)
What devices are we actually targeting? Kindle doesn't read EPUB, and many other readers don't yet support EPUB 3 Suggest we take this off the list of immediate deliverables since it isn't quite baked yet and probably the least likely format needed at this time. Format is not yet entirely stable so let's hold off for now
d. TXT (dissension in the team) I am hearing strongly worded opposing feedback re: the plain text output. Back to starting assumptions: 1 - we have the general requirements laid out in RFC 6949 2 - having at least one plain text version continue is one of those requirements. 3 - plain text has been synonymous with ASCII text; while that is changing over time, that is what was intended in RFC 6949
HF is not hearing consensus - suggest writing them down as potential end points, and ask the community which are truly requirements and which are not, but we probably still won't' hit consensus here Creating alternate outputs will be easy as long as we can leave lots of white space where necessary Principles (Dave) * one way to deal with lack of consensus is to say there will be multiple TXT outputs * if you have to make a choice and you have lack of consensus is to stay with current practice
Should the new tool chain allow for paginated text output that is exactly as good as what the RFC Ed team produces right now from the nroff, that will make the tools very complicated if it is sufficient to have something ALMOST as good without the fine tuning of vertical whitespace, then we have more flexibility
With the variation in TXT being requested, we could either allow all of the options, but very concerned about making too much diversity here. Maybe just be happy to make the ASCII version “ugly” and point people to HTML for a better reading experience. Give them the status quote, and it will have ugly text escapes, all the controls you want, widows and orphans.
Still concerned about what's useful to the reader, how not to confuse the readers;
e. SVG (probably not) see: https://www.rfc-editor.org/rse/wiki/doku.php?id=design:svg is there anything else that should be on the "just say no" list? Or is this sufficient?
f. XML (need a profile similar to what we're pulling together for SVG)
see above discussion under 2.
3. Input from Sandy from a face-to-face meeting last week
a. Biggest concerns: any major change in process will require training and an associated delay in processing docs Brainstorming some ideas, but haven't found something we're ready to recommend yet
b. What should the authors review at AUTH48 - the XML (which is the canonical version BUT which they may not know or understand, since they will also have the option to submit plain text), or one of the publication formats?
From Paul: This leads to three new requirements: - the Production Center keep an archive of XML as it enters the RFC editing cycle- the tool can produce output formats from any version of the XML, not just the current version- new diffing tools for comparing versions of unpaginated text and HTML This will allow the Production Center to say in AUTH48 “here's some diffs from what you turned in to us; review the ones you care about”
c. the amount of time doing testing is a concern - editor != QA tester d. other tooling will be required on the Publisher side, including updates to the underlying database, changes to the search and info pages e. where do links go? Will PDF formats only point to other PDF formats when one RFC links to another? similar question to the other formats
Non-ASCII characters outside of authors' names - the IAB i18n gang is looking at this - there is intentional distinction in where the author name appears; there is a table on the wiki that provides rough areas to structure the discussion; an enumeration of cases - the goal is to allow what we can that won't break stuff - we do have people's personal opinions, but there is no direction from the i18n at this time; can we come up with a set of principles to help guide the RFC Ed