RSE Wiki Archive

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.

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.  The important things are the diagrams, but will check the words as well to see if the idea for a filter might work.

b. HTML requirements

Does the HTML requirements draft need to change to allow for the more complete headers as described on rfc-interest, or is that something that would happen as something like a frame (but not a frame, since frames aren’t allowed in HTML5)

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.  Could use an iframe and include information that changes every time, but that is riskier.  Offline reading would end up with broken link looking stuff.  

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.  Would prefer the look be the same no matter how you got to it, and Joe’s proposal would have that effect.  (Paul) his proposal would be as well.  There’s the straight HTML, and then the HTML landing page.  (Dave) this would be two separate URIs?  Yes.  Don’t want 2 ways to get to the same page.

Tony: whatever we put in writing needs to be site specific.  The HTML version of the doc, but the meta stuff is the stuff that’s site specific.  There might be different meta stuff for I-Ds that’s not on the RFC ed page.  (Paul) the processor that is making an I-D would not put this in. This is extra information outside the HTML itself.  (Joe) it is ok to have a difference between RFCs and I-Ds, but not ok to have RFCs in different places looking different ways.  (Paul) Tony’s idea means this would be something the web server would serve up, not be part of the RFC.

Alice: if the XML file doesn’t change, then it can’t produce the HTML that shows post-publication metadata.  (Joe) it wouldn’t show the data, it would show a link to the data.  The fact that errata exist, doesn’t need to go in the thing we serve up; we just need to include the link to where errata would be if there are any.

Julian: that link already exists, so are we just talking about making it more prominent?  (Joe) this is just making it easy to get to from the RFC itself.  (Paul) If you follow the link within the RFC, you are only getting a few more bits of information.  (Julian) it would be nice

Dave: What does the tools site do now to add that header they use? (Tony) it polls the database periodically, and recreates the static file.

Heather: is this something that requires vocabulary change?  No.  is this something that totally happens in the processor?  Yes.  

Tony: What happens when I generate my own copy with my own tools for my own review?  It wouldn’t go to a particular site.

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.  The metadata for RFCs change.

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.  Would prefer that the HTML that we generate either contains links that are always correct (like the info page).  

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.  People opposed to javascript could turn that off and just have the broken links.

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, but not recently; reaching out to Larry Masinter to see if he has time to assist further.  Tony’s next step is to do some rounds with Larry on the doc and publish -00.  If don’t hear back from Larry by the end of the month, will find another person to help out.

d. v2
Made some progress with research; Paul created some tests for open remaining issue, and Julian created some more for additional edge cases.  Fixed his own generator to be more consistent with the other ones, but one open issue there (the question on how text pages and figures numbers).  Hope to have that resolved by next week then pretty much done.  Would be good to comparison reviews between v2 and v3.  Would be good to point people to the doc that is supposed to document current state.  No specific idea to who might be a good reviewer for this.  Maybe have the xml.resource.org page as the description of the vocabulary to help with awareness of the doc (Tony to add this).

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.  Are we now allowing some?  (Paul) No, PIs are not allowed in the canonical XML.  The features that are currently PIs that are needed have been added as new attributes.  It may be that people want more than those, but the design is “the ones we know will be important need to be attributes to rfc, and everything else can stay as a PI that the processor that makes I-Ds can still use.  We don’t want to jam a larger number of attributes

Alice: what about raced style PI?  (Paul) assume that if the RFC Editor is generating it, it will be in raced style.  They will be written into the processor, not toggled with PIs.

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) what if they’ve done spacing control for vertical whitespace, or half their lists to be squished and the other half not.  (Paul) there is no PI for compact vs. no compact.  The control of vertical whitespace is in the grammar not the PI.

Alice: just because there are other output formats doesn’t mean people won’t want to micromanage their text output.  (Paul) if the concern is that the RPC doesn’t have enough control, then we need to adjust the elements.  (Alice) has concern about different capabilities being enabled for I-D authors vs the RPC.  (Paul) that’s thy the list sent last night doesn’t include any formatting info.

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.  The text output will be best effort, but we’re not going to micromanage it.
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
RSE Wiki Archive

User Tools

Site Tools

Page Tools
