User Tools

Site Tools


design:20150120-notes

Attending:

Julian, Nevil, Paul, Alice, Tony, Heather

0. Agenda bash

1. Draft review - xml2rfc v2 draft - testing the *refs; Julian hasn’t had a chance to work on those; hopes to get to this before the end of January

- xml2rfc v3

Paul: had a a few changes today thanks to some input from Miek Gieben through rfc-interest.

  • What to do about xml:base and XInclude?

Julian: We decided that rather than inventing our won inclusion, we would use xincludes. What that means is that we don’t have any inclusion elements in the vocabulary, we just rely on the inclusion being down before our own code sees the documents. That can mean a pre-processing step or it can mean the xml2rfc processor does it transparently. But, as Miek observed, if you have a source document that contains include instructions, it will not be valid in the v3 schema. The other issue is that the xinclude spec

Having the attributes on the elements that were replaced can be useful, but if the processor includes that, then the resulting document will not be valid according to our vocabulary. We can say if you want to validate the document according our schema you have to strip the attributes. Or, we can allow the attributes in the generated documents. Both options have pro’s and cons.

Tony: we should allow the attributes, at least where we expect includes to be generating stuff.

Julian: two obvious candidates: references and artwork

Paul: but if we do that, we have to say that those are the only places where you’ll have valid afterwords, so if you use xinclude anywhere else, then you are going to generate unvalidatable code OR we’re going to have to post-process and the processor will have to be smart enough to know what to strip and/or what to leave in.

Julian: if we allowed them everywhere, it would make the grammar ugly.

Tony: think we should allow it everywhere.

Paul: what if we have two different grammars - what we have today, and one with optional xml:base everywhere. We could have the readable grammar and the real grammar, and the processor would take the real grammar and turn it into something readable.

Tony: would need to very carefully describe what the differences are.

Need to discuss this on the list, including fleshing out actual use cases. Need to resolve this in the next month.

- PDF

Tony: made a variety of edits to the document, still have more to make. Larry Master has a few sections to update as well. Note that Tony will be gone all next week, and really hopes to have an update by the end of this week.

2. Timeline - Action item from last call: timeline for examples draft

Paul: Note that the draft is not complete. We have an example of v2, and a mechanical conversion to v3 based on Tony’s converter. People might find some problems in the v2 to v3 converter, and those should be fed to Tony. We didn’t had many new interesting examples to v2; instead of using the document as a template of a v3 doc, it will be an example of this feature in v2 will convert to v3. There will be a separate examples doc for just v3.

So, need to add more interesting things from v2 and how they will appear in v3, and more examples of v3 stuff. We might do an example of v2 that is full of deprecated things where no conversion to v3 will happen.

Robert: is this document the place that will be a repository of instruction on how to deal with deprecated elements, or is that captured somewhere else? That’s captured in the v3 document. If it’s not, then that’s a mistake.

Paul: the examples draft is for developers and people creating their own converters. It is not an instructional guide for upgrading.

Alice: the xml2rfc FAQ could be updated with “how do I get it to do foo” questions.

Robert: There is a test document that the xml2rfc code suite uses as part of regression testing. Would it be reasonable to run that through Tony’s converter and do necessary fix ups, and so have a starting place to use that as a v3 test document.

http://trac.tools.ietf.org/tools/xml2rfc/trac/browser/trunk/cli/tests/input/draft-miek-test.xml

Pointing to a v3 test document, based on the v2 test document, should go in the SoW.

Tony: the v2 to v3 converter didn’t have any errors when run against draft-mike-test. Whether that is the output we actually wanted is still open. It needs to be reviewed by hand, and we should really finish the examples first to make sure the converter is doing what we want.

Robert: looking at the publication converter, can finish up that SoW by pointing at the examples and the v3 document on how to deal with deprecated elements. The last thing that Robert doesn’t have a hook for is if we have a set of hand crafted work examples for a v3 input and associated html output. Team needs to review the publication formatter SoW, since it mostly points to this team’s outputs.

3. AOB

Alice: Regarding the tables and whether a center attribute needs to added to every box, what was the conclusion there? On v2, the centering of the heading is inherited by the rest of the column. In v3, it has to be explicit.

Paul: we should be explicit.

Julian: Are we sure that centering heading implies that the contents of the column should be centered?

Paul: OK with people being more specific.

Julian: v3 shouldn’t be harder than v2.

Paul: we are going to be arguing about what different kinds of users might like different things. Tables are going to be more interesting when they hit reality, and v4 may end up focusing on tables.

design/20150120-notes.txt · Last modified: 2015/02/03 14:08 by rsewikiadmin