User Tools

Site Tools


design:20141028-notes

Attendees: Tony, Sandy, Joe, Paul, Heather, Robert, Julian

0. Agenda bash

1. The plain-text submission scenario and canonical format

“If the output is good, by definition the XML is good. If the output is not good, then either the XML _or_ the tool is not good. Therefore, it doesn't matter who creates the XML, it can remain canonical as long as the author indicates the output created from the XML is as intended.”

What will it take for me to be better with this?

  • we know we can programmatically validate that the XML is valid
  • authors outside of this review team seem to review XML by running it through a converter and looking at the output; they only look at the XML when something doesn’t render correctly
  • a transition period where the author has to review at least 2 of the outputs?

*DEBUG CSS*

more a desire to say to authors that they are approving the XML (even if they are not reviewing it directly) by approving the output(s)

2. Draft status

  1. HTML

Joe: Expecting an -05 with nitpick-y stuff (e.g., forgot to put the XML in at the end in a comment)

Heather: CSS draft comes next; needs to be informed by the HTML

Paul: there are things we are now doing that will need to be informed by more than just the HTML draft; there will be new stuff that will only be in the CSS (e.g., reference group) - How will references look in the reference section when multi-doc?

Robert: the draft we have for the example v2 to v3, having an HTML output based on that example v3 would be really helpful

Joe: has a test.3.xml, and that’s a v3 format doc with one of everything, and there is a test.n.xml, which a result of applying the numbering operation to that file, and then there is a test.3.html file that is the html that has had transforms more or less applied. Some bugs here and there, but largely done.

Robert: yay!

Heather: do we need same level of detail for plain-text or PDF? Joe: or you could just say “it needs to look like the HTML” otherwise yes, you need that level of detail

  1. PDF

For the next version, I’m assuming that an element-by-element set of instructions to say “this element in the XML should do the following in the PDF” would be helpful - or am I fundamentally misunderstanding the nature of the PDF?

Tony: Several comments sent by Robert. Need to look at the HTML draft to see how that needs to inform the model into PDF

  1. XML v3

pagination hints - I’m following the rfc-i conversation, and as I mentioned on that list, I think this is something we should hold as a “wait and see if it is actually needed/useful and required vocabulary changes rather than code control”

Paul: Changes in last version were mostly from working with Joe on the HTML

Boilerplate

As Joe was doing the HTML transform, remembered how difficult it is to create the boilerplate correctly; many combinations, not intuitive on what needs to plug in together. Appalled that each format writer would have to create that work and potentially get it wrong.

Paul: If there is a separate tool that takes the input variables and spits out XML v3, then it will appear in the XML where anything else has to render it, and they would render it as normal sections.

Robert: would have to be very clear about the submission process and how this tool might impact it.

Julian: so you want one piece of code generating it, but an easier way to get there will be to have one formatter to generate the outputs?

Robert: focusing on the IPR and boilerplate, we leave a nicer trail if the same words are in the XML. Embedding the generated boilerplate is the archival format is a smart thing, but should make sure we don’t lose the information we used to develop the boilerplate. We must preserve the IPR attributes so an automated too can verify that the archived format matches proper boilerplate.

For the IESG discussion, suggest that I-Ds submitted for approval must have been run through to look like the archive formatter.

3. AOB

  1. IETF 91: no good time to meet
  2. Robert’s message re: headers and footers and an idea from Paul to go along with it

Paul: currently there is a contradiction that non-canonical text has only running heading and footers, but the non-canonical PDF will have headers and footers. Assuming we can fix vertical spacing in PDF, we generate the text from the PDF and that would then include headers and footers (but it probably wouldn’t be printable)

Julian: people who want the text format want it for more than copy-and-paste. the headers and footer swill be the same as HTML as would be displayed on a page device.

Joe: that’s probably CSS

Julian: it goes into the paged-media CSS. The only problem is if you want to extract it from the HTML

Robert: the v3 support for running headers and footers was removed;

Julian: then that needs to be re-added

Paul: easily done

design/20141028-notes.txt · Last modified: 2014/12/17 07:57 by rsewikiadmin