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, Julian, Paul, Robert, Tony, Nevil, Joe

0. Administrivia
- Should have Gen-ART reviews for v3 by end of week

1. v3 and multiple ways of handling <reference>
- See Paul's email "Subject: [rfc-design] The state of <reference>” from 3/31/2014
Has added what we talked about on the list, but it’s looking ugly and too much.  Maybe we leave it, and decide that the canonical format will just use one of the ways to do things, or we can clean up what we have.
Cut and paste might be the right answer here, despite some people’s concerns.  We won’t find a solution that’s good for all the major use cases (I-Ds, RFCs, other SDOs).  There will always be two kinds of things that we can’t cover, including things like journal articles that we won’t generate automatically.  People will need to be able to add these by hand.  Also, SDOs for which we do not have coverage for currently.  In those cases, we want the doc author to be able to enter a properly formatted reference in some way.  If we want to try and do some help, we should do it in fewer not more ways (which is against where we were last week).  Last week we’d talked about focusing on including from a list or the web.  

Alice: why are we moving away from the mix available today?  (Paul) we’re not, we’re just asking how to make it easier for people and if so how much.  That leaves us with four ways of doing things.  (Alice) in favor of sticking with the unwieldiness to be similar as it is today

Tony - the include URI and file are reactions to this case that the current include mechanisms.  The way the include PI works in the current xml2rfc is that has a path defined for where to look for the reference, including the local cache, a user-provided library, and the URI prefixes to look online.  That’s unwieldy also.  Not sure the include URI and file captures the same capabilities as the PI did (i.e., cache, local library, path).  These are all implementation details.  (Paul) would you be ok if we pulled out the two additional things and just left the PI for local processors (which would be new)?  If the audience we are trying to help are the people who are using the tool in the current way today, we could continue to support that and then have other people go to the new way, which would mean Paul has to flesh out how the include would work.  (Tony) we need some kind of testing to see if/how this will work (which is not part of the draft itself).  (Paul) there is some confusion about what the draft processor will do and what that means (Julian) when you say “draft processor” you mean the processor running against the I-Ds submitted to the ietf website?  (Paul) you can’t submit an I-D that says has a PI that says “grab off local disk”.  (Tony) Yes you can.  (Paul) saying you can do that with the new vocabulary described, just not in a PI.  (RjS) there is also a time component; cut and pasting manually is inefficient and by leaving this as a URI until the last minute means you’ll capture the latest changes to the reference.  (Tony) note that the entity references are still a possibility. (Paul) hoping to make the need for entity references go away.  (Tony) if you don’t have the include URI in v3, you will have to have the entity references. 

Julian: the accessing processor already has the feature of generating XML from XML; for people that runs the processor locally, they can run this locally prior to submission.  Regarding including external entities, didn’t we talk about using Xinclude which already does most of this without entity references, etc.  (Paul) agree with the first point, that running the tool just prior to submission should be fine.  Regarding include, still waiting to see the specific proposal on where/how to use it since it is a fairly generic tool.  It may be the right tool, but need more detailed information.  (Julian) it is a feature of xml processors that they either have or don’t; will make an example of what this would look like in practice.  (Paul) we talked about Xinclude for references, but also for code.  We need to make a decision there as well.  (Julian) Xinclude is either on or off, so we can’t really say “use it here but don’t use it there” in the same draft; Xinclude is just part of the tool.

Tony: the syntax can be very very simplistic.

Paul: Tony, are you ok with the processor emitting XML?  The current way we think of the processor when run local is to submit XML and get out text.  Are you ok with the processor emitting XML as well as text and other formats, and that the new XML is what gets submitted?  (Tony) that’s more a question about how I-D submission should work. (Paul) so if all the Xincludes are as URIs, that should be something someone can still turn in.  

Paul: it doesn’t sound like we have consensus here yet, so will take out for more public comment

RjS: we are scope creeping a bit into I-D, which is of interest, but the design team is focusing on the Canonical Format.  (Paul) Yes.  If the IESG is reviewing a doc that is not self contained, then they what they approve may change.  (RjS) the vast majority of XML I-Ds currently point to (mostly) reasonably solid repositories.  Expect that the answer that will come back is “we need to do both, and we need to know what we’re doing, when we’re doing it.” and then they will try to solve the problem instead of answer the question.  (Nevil/Paul) we cannot have different draft submission rules for the different streams

Paul: will talk to Heather about next steps here.

HF’s summary: Alice is concerned that we don't lose the functionality we have today, even if it means somewhat heavier vocabulary.  Tony is more concerned about what this means for I-Ds, which is important but something I can only advise on.  Robert has a very good point about what the IESG is likely to ask for if we give them options.  And Julian is going to provide a sample Xinclude chunk.


2. status of the non-ASCII draft and non-ASCII character tagging
- (not sure if Joe/Henrik/JCK have had any side conversations since the last burst - issue is still unresolved afaik)

Julian - Henrik made a proposal in London, and there was some agreement it would be useful, and Joe said I can check that with a regex and sent a proof of concept.  So now we can flesh out what the elements look like.

Joe - authors who are using these characters are (hopefully) people who are more familiar with what actually needs to be done and that the output is what they expect.  Coming up with vast amount of tooling ahead of time is premature and will add enough overhead and complexity to prevent us from making forward process in a reasonable time frame.  We also don’t know enough about the requirements yet and have to have some real world experience first.  (Julian) we should wait with this until we have practical experience.

Paul - agree with Joe, and would add that the first steps should be proceed as we are now with a lot of review; we can add something into the SoW for the processing tool that says “if you see any international characters, give the person processing the doc information about those characters”; that would reduce the amount of surprise.  The tooling can do some hand holding here.

Joe - for this first, info gathering period, the tooling would issue a warning for every character above 127 and it would give the line number, code point and code point name out of the unicode character base.

Alice - we had talked in the past about having a set of expert reviewers: one that says whether that’s a reasonable use of a non-ASCII character, and another set of reviewers that verifies that the thing says what it says it does (e.g., if it is in Russian, we have a Russian speaker verify the text)

Tony - it would be appropriate to have it done earlier, as part of Last Call; (Paul) maybe when the tooling sees an I-D comes through with non-ASCII characters, that it sends an automated note requesting a review.


3. HTML landing page, continued
Still interesting discussion on the list.  Is anyone here still locked into javascript in the thing you get from the RFC Editor when you click on a link that takes you to “this RFC”?.  (Julian) Yes, unless someone demonstrates something better.  (Paul) then we need more discussion and examples on the list.  

Joe - one of the things we’d talked about is that we would have in the static HTML a link to the page where you would get the extra information, and that if you had javascript enabled, that link might get replaced or added to with the info with what’s on the other side of the link.   (Paul) not sure about the model then.  Taking the model of “has errata”  (Joe) the HTML file itself only has a static link that never gets changed, or gets refreshed once an hour (at which point the javascript isn’t as important) (Paul) for this example, mirrored last night, so does the HTML say “there is no errata” and the javascript would change that, or would the HTML be silent, and would have to click on the link to get the latest information?  (Joe) preference for the second so we’re not constantly changing the HTML file.  (Julian) having the HTML file by default without the extra metadata, and inserting when it becomes available through javascript should be ok.  (RjS) where does the javascript live?  (Joe) don’t host it in the page, host a link to it in the page; this would be a static link to the script itself.  (RjS) the notion that the part of the community see the errata, and the part that won’t will turn into a flame war.  The doc shouldn’t say something different when it’s done.  (Julian) it should be clear that the information of the errata, obsoletes, etc
is not part of the RFC, and it needs to be styled properly so that people can recognize where the information may be stale.  (RjS) people would probably would accept that.  (Paul) people would probably accept this more than have the javascript update what’s posted with the HTML  (RjS) “this javascript will get info from this link that you already have available, just to make things more convenient for you”  (Joe) and the javascript will be open source and fully audit able

RjS - when you talk about this outside this group, it will be very important to quickly shine the light on the presentation format of an RFC that can be stored and rendered from those stored bits somewhere else, and not what the RFC Editor would be serving on their pages that happens to be HTML pages.  (Joe) want to make sure the HTML file isn’t different - should be just one version that never needs to change for this kind of thing


4. AOB

— PDF update - Tony has a meeting with Larry and others PDF experts at Adobe tomorrow
RSE Wiki Archive

User Tools

Site Tools

Page Tools
