User Tools

Site Tools


design:20150428-notes

Attendees: Joe, Paul, Tony, Robert, Julian, Heather, Nevil, Alice

Notes:

0. Agenda bash

1. Draft review

  • xml2rfc v2 (*ref review status)

Julian: need to finish discussion the finalizer discussions since that will impact the *ref stuff; sent an example earlier today and needs the team to think about it and offer feedback; there is a balance in minimizing the output in HTML code and the desire to have the same text content no matter the output format

Joe: if we can’t use the text for this the way we spec’d in v3, the finalizer can add a new attribute instead; just need to specify how that will work

Joe: We should be able to generate the text output from the finalized XML; whatever info in the v3 format to do that with the text formatter or any formatter not having to be particularly smart. In the case of links, some of those when you print the HTML format, we might print more hints about where it’s going to instead of the link, so it might look more like the text format (different display on screen vs on paper). For the short term, figure out how to get all the info we need in the v3 xref element, so the v2 format still works but the v3 formatter still works. This turns into two distinct issues that can be handled separately.

Paul: going to Julian’s example from today (4/28/2015) what attribute? One or more that contain actual section name and actual section number. The finalizer will have done an analysis of section numbers and stick them in.

Joe: this would help consistent numbering across all format.

Julian: was concerned about a specific part of the vocabulary being overloaded; this helps solve that issue.

Joe: believe we can probably that even in the case of structure, a sluggified version of the plain text with all tags stripped out would work. For control purposes.

Tony: the PDF shouldn’t differ from the HTML generator, so this should work for PDF as well

  • xml2rfc v3

Paul: put out a new I-D, no comments yet

  • Examples

Alice: is a secondary goal that some reading it would understand more of what changes between v2 and v3?

Paul: thought this doc was just to target tool testing, not people understanding. Why would a list of changes be here instead of in the v3 draft? The examples draft will not become an RFC. Maybe some text at the beginning to help explain the purpose of the document.

Alice: thought this would be both a useful example to the person and an input example to the tools.

Paul: but at that point it would be an RFC, but the examples are more contrived than would be appropriate there. Possibly better to beef up section 1 of the v3 draft, or create a new draft with more details of examples.

Alice: an FAQ plus the v3? The examples should be update-able

Joe: doc in the HTML repo is all the combination of tags to test against; a unit test of v3. The current unit tests: https://github.com/hildjj/draft-hildebrand-html-rfc/blob/v05/test.3.xml

Paul: v3 draft can point to an FAQ that doesn’t exist now, and we can work on that later

Robert: for the existing examples draft, the focus is on v2-v3 translation; add text that there are other things you can do in v3 might be a strong enough hint to look elsewhere for good v3 behavior.

  • HTML
    • title/@abbrev value
    • section/@toc value

2. Finalizer discussion (if you haven’t read the thread, read it) Principle: outputters should be as stupid as possible, and final output should be as similar as possible

The things we submit as I-Ds do not need to be canonical; initially, people can submit v2 or v3. Overtime, you will translate from v2 to v3 for formatting, and overtime we will expect just v3 (just for I-Ds). RFC Editor can follow a similar process, or not, as needed.

When should the finalizer step runs? Along with idnits?

Tony: the XML in the I-D repository should be an editable, not finalized version.

Paul: why can’t edit a finalized draft?

Tony: finalized would strip out comments

Julian: expanding all attributes to have all values in-line also destroys editability.

Joe: we could have a de-finalizer to make it easier to edit. Losing comments would be a prolem. Maybe multiple finalizers?

Julian: the finalizer and the other step for formating might not be the same for everything. Maybe give it a different name?

Joe: finalizer would run before the formatter; if it outputs, it outputs the canonical XML The outputs need to be the same.

Paul: if turning in a draft as XML, the datatracker would do a finalization as part of the submission. Shouldn’t call this a finalize

Tony/Julian/Paul: there needs to be a spec on the format of the sluggified name; we need to at least create a best initial effort, knowing we will never reach all the edge cases

Joe: writing such a spec would be horrifically difficult and is unnecessary because it doesn’t matter what the sluggified names are, they just need to be consistent for the all formats of a given draft

(Ask Joe to write down what he means by the output and sluggified names; not picking it up on the call)

Heather: understand Joe’s stance that a spec defining how to create the sluggified names isn’t necessary; asks that Julian, Tony, or Paul write up why they disagree and post to the list

3. AOB

design/20150428-notes.txt · Last modified: 2015/05/12 23:06 by rsewikiadmin