This shows you the differences between two versions of the page.
— |
design:20141202-notes [2014/12/02 14:03] (current) rsewikiadmin created |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | Attendees: | ||
+ | Joe, Julian, Nevil, Paul, Heather, Robert, Tony, Sandy | ||
+ | 0. Agenda bash | ||
+ | |||
+ | 1. deprecated/ | ||
+ | (From Heather’s email to rfc-design) | ||
+ | We could say that we will continue with the deprecated/ | ||
+ | for vocabulary items out of v2 (since it has never been canonical) but | ||
+ | continue support for the v3 vocabulary in perpetuity, regardless of | ||
+ | future changes and enhancements to the vocabulary. I'm not thrilled | ||
+ | with that, but I think it could be a reasonable compromise. Thoughts? | ||
+ | |||
+ | Joe doesn’t agree with the approach to the email that Paul drafted. | ||
+ | One, HF has said pretty directly that the canonical documents to be published will be valid v3 without deprecated features (leaving aside forward compatibility for the moment). | ||
+ | Given that, at some point in the tool chain, we are going to be generating a valid v3 without deprecation XML document. | ||
+ | So, the way to think about this is: there are configurations of the tooling that might generate warnings, errors, or nothing for different settings of the configuration parameters. | ||
+ | |||
+ | Paul: that captures the conversation, | ||
+ | |||
+ | Robert: I followed, I think it’s the right target | ||
+ | |||
+ | Julian: what does this mean for Paul’s draft as currently written? | ||
+ | |||
+ | Joe: there are a couple of things to do in Paul’s document. | ||
+ | |||
+ | Julian: agree having the mapping written down will be a good thing; not sure it needs to be in the v3 draft. | ||
+ | |||
+ | Joe: would rather not have to jump between documents, but can be convinced if you have a good use case. Once you have the rules in there, | ||
+ | |||
+ | Julian: the main concern is writing down the mappings might slow us down, but since this won’t be finally published, that’s ok? | ||
+ | |||
+ | Joe: yes | ||
+ | |||
+ | Julian: summarize: we will stick with original definition of deprecation, | ||
+ | |||
+ | Joe: suggest Paul to take a look at the mapping tool, and pull what you can out of there? | ||
+ | |||
+ | Tony: that test document should go in the examples draft. | ||
+ | |||
+ | Joe: No, we need something just to test edge cases; examples should guide people to what we actually want them to do. | ||
+ | |||
+ | Paul: this means Paul needs to look through the v3 document at what’s marked deprecated, where it says “instead use such and such” and turn that into an actual set of mappings | ||
+ | |||
+ | Joe: one other bit, a tool requirement. | ||
+ | |||
+ | |||
+ | 2. Where to put DOIs? | ||
+ | |||
+ | (From Paul’s message to rfc-interest) | ||
+ | In order to have DOIs in both locations, we can: | ||
+ | 1) Leave it in < | ||
+ | 2) Create <doi> to be part of < | ||
+ | |||
+ | Paul: would like something that works equally well for the reference as well as for the specific RFC. | ||
+ | |||
+ | Joe: agreed. | ||
+ | |||
+ | Julian: it would be nice if that was the case, but it’s already confusing now with the attributes on the rfc elements. | ||
+ | |||
+ | Paul: agree this would be good, but now might not be a good time; this is a lot of work | ||
+ | |||
+ | Joe: if we don’t it now, we will never get it done | ||
+ | |||
+ | Julian: willing to look at it again, and writing it up for the team to consider. | ||
+ | |||
+ | Joe: we don’t have bibliographic references for BCP and STD, so we are going to have to come up with something and this could help that. | ||
+ | |||
+ | Julian: really don’t want to add something specific for DOI; should be generic | ||
+ | |||
+ | |||
+ | 3. Draft status | ||
+ | - plain-text | ||
+ | - non-ASCII | ||
+ | - HTML (bunch of comments to review and possibly incorporate; | ||
+ | - PDF (no progress since Hawaii; hopefully will get back to this later this month) | ||
+ | - XML v3 (we have pending issues from Jim Schaad that are updated in a revised draft, but am waiting for Julian to do the many little updates needed for v2; will go ahead and push it out now) | ||
+ | |||
+ | For numbered things, we have four names: figurenumber, | ||
+ | |||
+ | 4. AOB | ||
+ | |||
+ | (From Julian) | ||
+ | 1) I discovered one left-over TODO in the v2 spec. I'll try to get to that asap, | ||
+ | and then post a new draft. (as draft-iab...? | ||
+ | 2) I started to cherry-pick features from the v3 spec for support in my XSLT | ||
+ | code; and started to use those in the v2 draft. See: | ||
+ | < | ||
+ | documentation and | ||
+ | < | ||
+ | for the HTML generated for the v2 draft. | ||
+ | | ||
+ | Tony should look at Julian’s documentation on this, to see how it might feed the conversion code. | ||
+ | |||
+ | (From Heather) | ||
+ | I'd also like to add a discussion on the following: | ||
+ | "One of the SoW, probably the presentation format converter, needs additional | ||
+ | text pointing to a description of the processing that will be performed on a | ||
+ | v3 document before publication as an RFC (things like calculating section anchors | ||
+ | and including the expanded boilerplate). The description itself will likely land in | ||
+ | the framework document." | ||
+ | |||
+ | Much of this will have to be things that land in detailed instructions to the programmers. |