This shows you the differences between two versions of the page.
— |
design:20140326-notes [2014/03/26 14:29] (current) rsewikiadmin created |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | Attendees: | ||
+ | Alice, Dave, Heather, Joe, Julian, Nevil, Paul, Tony | ||
+ | |||
+ | Apologies: | ||
+ | Robert, Adam, Ted | ||
+ | |||
+ | |||
+ | 1. Status of drafts | ||
+ | a. SVG profile | ||
+ | |||
+ | No changes made. Been working on diagonal lines, but that broke everything so had to do a lot more work. Hope for a new rev in the next 1-2 weeks. | ||
+ | |||
+ | b. HTML requirements | ||
+ | |||
+ | Does the HTML requirements draft need to change to allow for the more complete headers as described on rfc-interest, | ||
+ | |||
+ | Joe: could have a set of well-defined URLS that you could construct from the RFC number, and put that URL in the HTML. That would be relatively safe and wouldn’t cause much damage. | ||
+ | |||
+ | Paul: suggest sticking things into a div, and put the div in the CSS so that it could be turned on or not for each user. (Joe) as long as it’s relatively discrete, it won’t hurt anything. | ||
+ | |||
+ | Dave: not sure understood Paul’s point. | ||
+ | |||
+ | Tony: whatever we put in writing needs to be site specific. | ||
+ | |||
+ | Alice: if the XML file doesn’t change, then it can’t produce the HTML that shows post-publication metadata. | ||
+ | |||
+ | Julian: that link already exists, so are we just talking about making it more prominent? | ||
+ | |||
+ | Dave: What does the tools site do now to add that header they use? (Tony) it polls the database periodically, | ||
+ | |||
+ | Heather: is this something that requires vocabulary change? | ||
+ | |||
+ | Tony: What happens when I generate my own copy with my own tools for my own review? | ||
+ | |||
+ | Julian: the problem with the processor generating this is that the information changes over time. The generator could look at the current status of the database, but the document that is generated would be different every time the HTML is generated. | ||
+ | |||
+ | Dave: the way the tools site works to recreate non canonical format | ||
+ | |||
+ | Julian: but it is not dynamic, and if you have a copy from the RFC from another site, then that information gets outdated and copies drift. | ||
+ | |||
+ | Joe: if the default link for the offline use case and there is javascript that pulls the status and replaces those links with the actual status, then it would solve many people’s problems. | ||
+ | |||
+ | Tony: I-Ds don’t have errata. | ||
+ | |||
+ | This all couldn’t be done with just CSS instead of javascript, since it’s collecting current information. | ||
+ | |||
+ | Julian; if we do this, the network requests that are begin sent every time you open an RFC are properly handled by the server that we are requesting data from; all the things we need are static XML or JSON files that cache information so the RFC Ed web server isn’t DOS’d. | ||
+ | |||
+ | Alice: the tools site is useful, but don’t want to do it the same way since sometimes it is out of sync | ||
+ | |||
+ | HF to write up the sum of the recommendations and request help in dealing with the areas of discomfort | ||
+ | |||
+ | |||
+ | Julian to prototype on his site | ||
+ | |||
+ | c. PDF requirements | ||
+ | Have some feedback on rfc-interest, | ||
+ | |||
+ | d. v2 | ||
+ | Made some progress with research; Paul created some tests for open remaining issue, and Julian created some more for additional edge cases. | ||
+ | |||
+ | e. v3 | ||
+ | Processing Instructions | ||
+ | Paul: sent a prerelease of the next version to the mailing list. It contains more info on the PI points raised over the last week or two. We are getting fairly close to top of stack on things he knows of. The places where there are holes include: | ||
+ | |||
+ | section titles can be elements, not attributes - have agreement | ||
+ | elements for auto generated text so it appears in XML as well - haven’t started on this | ||
+ | non-ASCII characters — a very big remaining issue; need to have a discussion on how that will finally work so Paul can determine if that requires vocabulary changes. | ||
+ | |||
+ | Alice; there is some question about outlawing PIs entirely. | ||
+ | |||
+ | Alice: what about raced style PI? (Paul) assume that if the RFC Editor is generating it, it will be in raced style. | ||
+ | |||
+ | Paul: there are three different level of processors: the processor that creates RFCs, the processor that creates I-Ds, and the processor that anyone feels like designing for themselves. | ||
+ | |||
+ | Alice: don’t follow there being separate processes (Paul) it could be separate processors, or one that has two separate states, like an option on the command line. It should conceptually be one piece of software that will do either based on its environment somehow. | ||
+ | |||
+ | Alice: if an I-D is approved and it has PIs, what does the RFC Ed do? How will that work? (Paul) the list of PI used for drafts doesn’t effect RFC Ed? example: the editing one that sticks in paragraph numbers. | ||
+ | |||
+ | Alice: just because there are other output formats doesn’t mean people won’t want to micromanage their text output. | ||
+ | |||
+ | Paul: this is making the assumption that people are using v3 for drafts submitted. | ||
+ | |||
+ | Julian: at some point in the past, we agreed that we would create plain text output but it may be uglier than the other output. | ||
+ | Alice: concern that many authors and the RPC | ||
+ | |||
+ | 2. From Design to Tools | ||
+ | a. Getting the Tools Team spinning up on what's needed | ||
+ | HF to write up in email |