Expected attendees: Paul, Robert, Heather, Sandy, Joe, Tony, Nevil
Apologies: Julian
0. Agenda bash
1. Administrivia
a. Project timeline
What does this team have the appetite to finish?
Is it possible to have the various drafts that have been already been started in a mostly-finished state by IETF 91? Because we’ll need to have things done enough to get the SoWs out for community comment (4 weeks, minimum), then create RFPs (another 4 weeks, minimum), etc.
Tony: wants to verify that we’re not publishing until we have running code
Heather: correct
Tony: “mostly useful” is a different criteria than “spit and polish”
Paul: there is a difference between figuring out community consensus vs. think this is good enough, but we don’t need a community consensus call yet
Robert: pushing on the “mostly useful” characterization - we need to have enough of the design that we could send someone off to build code and not waste their time. Is that in the fit for “most useful”?
Tony: someone should be able to start implementing stuff, and come back and say “hey, this is was missed”
Robert: we aren’t there yet. The HTML draft is where most of the short term effort needs to go to get to “mostly useful”, and fall out from there will feed into the XML2RFC v3 draft
Paul: one reversal - we need to figure out what tables in XML will look like; it’s easy to say what tables in HTML will look like. But you’re right that our focus and community focus needs to be on HTML right now.
Paul: would change “mostly useful” to “if someone starts developing from the draft, they could finish developing but point out what code was poor because of the quality of information”
Joe: we can tell developers to start at a certain point, and let us know how it goes; treat the sections in priority order. This is a software engineering problem, not a design problem.
Paul: any doc needs enough good starting points that someone could get going and not have an architectural problem.
Robert: we have identified how we do major sections; layers of wrapping ids doesn’t really have design team consensus yet
PDF draft - needs buckling down
SVG draft - Nevil has some responses for the genART review
b. FYI on SoW drafts
2. HTML draft
Many open items posted on https://www.rfc-editor.org/rse/wiki/doku.php?id=design:html-requirements
“There are sections…” - Joe will look at this; Paul notes that this assumes you have XML v3; Joe will need to work with Paul
“3.2.10” - OBE
“3.2.13” - need to make sure that block quote in v3 has citation bits (it does); Joe will go through v3 draft and try to highlight what might impact HTML
CSS - punt on that, won’t help developers, and we’re likely to change our minds; we will need guidance to say this is an exceptional situation; make sure that where you KNOW a style attrib needs to be explicitly placed, make sure to say so, and we will tell the developer “unless you see instruction to use style directly, don’t” There are style attributes, and things that inform style. At the very end, we will have a complete list, but not now.
deployed browsers: this draft should say the RFC Ed will maintain a list of browsers we will be testing against, and strip the actual list out of the draft; post on the RFC Ed website and maintain there
Section 4 compressing instance - all that was about stuff submitted as HTML; we should talk about what to indent with (spaces, not tabs); also, let’s keep the ease of diffs as a motive, because some people will want to run diffs against the HTML. Since we are building a diff tool for the XML, diff-ing the HTML will be less of a normal workflow case. So, remove any reference to wrapped text, and let the tools team do whatever and we’ll see what feedback we get
indentation: first one, and the way to specify that is mixed content nodes don’t get new lines in the middle. Will probably pull out the whole indenting stuff too. Will put in something fuzzy about pretty-printed, don’t want it compressed or smooched up one line
div vs. non-div: make sure I got rid of the non-div wording
autogenerated tags: Heather to just pick something
How to write software that identifies security considerations? The IESG should have an opinion here. RFC Editor can recommend, but the IESG is the one that would require. The only mandatory tag right now is for abstract. We can have two lists: one for mandatory, and one for suggested. Or maybe just make mandatory and see who complains. Paul to add something here in XML draft. We’ll look at the name.
HTML5 - leave that up to the RFC Editor what we’re currently tracking, similar to browsers. The HTML5 people won’t use version numbers going forward.
classes instead of ids - Joe might have a counter proposal; the one Paul has is a starting place that might work as well; will have more info to make a decision after the id section is done
3. AOB
Examples for XML (Paul)
Julian has dropped off as co-author, and Paul has narrowed scope of examples to be towards the intended audience being authors trying to write XML; it will be a template for a whole document and then if there is a desire for examples of every possible element, that will be a separate document that will likely be not really human readable
this will not target the tools people, but Robert will need some kind of examples for the tools group; Robert won’t need comprehensive examples, but they the basic framework and where it is not obvious on what to do when you have been using deprecated elements; if we are providing the roadmap for those guys, the tool that will do the conversion will be able to be informed by that. Also expecting there to be an HTML product to be out of this effort, given this input here is what the HTML will look like. Paul will not do that. (Joe) XML is a prerequisite, so let’s get that first, and then maybe we can beg Julian to do the sample. Worst case we will generate it by hand.
SVG (Joe)
Joe ran a test of the SVG stuff - most of the browsers rendered SVG fine; the ones that didn’t rendered the description tag except lynx which rendered title and description; and in some the browser just failed entirely. So, we can probably count on the <desc> to help inform for browsers that can’t handle SVG. Nevil will do some more thinking about this and revise the draft accordingly.
Nevil: if you’re working on draft, it’s useful to use an image tag to pull the SVG in, and maybe one day we will want a well-define way for authors to submit the SVG that way.
