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.
** Next call scheduled for 23 October 2013 **

0. Agenda bash

1. Administrivia   
a. BoF = Thursday, 7 November @ 17:30-18:30 PST

Plans for BoF include: Reviewing the requirements; showing the mock-ups, opening the floor to comments and questions   
   
b. Daylight Savings Time ends in the U.S. on November 3

2. Requirements status   

a. TXT - joe to talk to me about normalization forms - important point is that these are just for comparison, they are not for human readable text - it's a think that you do to a string before you match, and they do tend to be lossy (especially the K forms)when we allow UTF-8 in a doc, should it contain NFC or NFD?  Perhaps it only matters in fields that act as protocol ???, such as names; what should be in the style guide for what the tools actually put in to there - it may or may not make a big differencethere will be examples where you want to have an option, such as example; but where there is semantic meaning, that's only where normalization forms; they should be applied before for comparisonThis isn't just a TXT question; it is a format independent question and is mostly up to the author as long as these are things that are widely renderable   

b. PDF - We have not heard requirements beyond what is currently being offered now, which is a PDF of the TXT   

c. HTML - See Alice's note
None of the items were red flags; the look and feel question is "how much is it going to look like the plain text RFC - at one end, you have the HTML on the tools pages that looks very much like them, and on the other we have something like Joe or Julians

Like the idea of a consistent look-and-feel, but not sure what that will mean, where the balance is

Shading behind ASCII artwork would, by preference, be nixed

Note that we use the <artwork> tag for too many things; we should keep in mind that once we have the proper way to mark up the source document to tell the tools what kind of artwork that is or even diff element names, we will also have diff HTML for the output; preference would be for us in the new XML to easily be able to say "the type of ASCII in this thing is "this" and that we have a sane and growable list - Julian says we already have this, but almost no one is using this because with existing tool, almost no tools use it
tooling requirements != rendering requirements; I should be able to bring several different rendered versions that all come from the same CSS

If we can stress we are developing the requirements on the HTML, not the requirements on the CSS, we can push off the need for universal agreement

the kind of questions "will your format allow rendering "blah"? will it allow me to render the section titles as a list? Am I going to be able to see links in the HTML?"  those are the kinds of questions to entertain, rather than questions on font, line breaks, etc

Will this display properly in a txt based browser?  that's actually a good requirement; if it can't render without CSS there is something wrong with it

For the final v3, we will have chosen a default CSS; anyone with the technical skill can change the CSS of any site they visit if they demand a different look and feel; if you want to do that, it is technically feasible; we want to make sure there is a canonical rendered form, where the CSS was chosen by the RFC Editor and accepted by people - the requirement piece, by the time we  are in the new world with a new format, those files are as self-contained as possible and will include the CSS so they will render properly and the expected thing(s) will happen

HF to write this up on the HTML requirements page

Need to remember to emphasize the "why" we went a certain route when we talk to the community about this in Vancouver
the requirement for the generated HTML has no formatting in it, the formatting all comes from the CSS   

d. EPUB (on hold)we need to note that it will be easy to separate by chapter; this would be a requirement for HTML since we had a conversation about containment or not and this makes that choice easier; we need to understand how to group things within HTML in to separate files when it comes to creating the EPUB output

it must be straightforward to separate in to different sized chunks, either by section or subsection or whatever

Will also need to consider the ToC so that it can be readily identified   

e. XML      - ("For XML, what we need is a statement that we will start with

what we have and will collect the set of things that we would like the things that XML would extend to in the future; Alice, Julian and Joe to write on that mid-term future; probably need to figure out what we're pointing at for now might be useful")      

- RFC 2629-bisboth items are essentially the same; Julian is working on the vocabulary as supported right now and it is a skeleton doc with no prose but just the structural info; will include information on what has changed and what we want to add in the future; will try to have this out as a 00 draft before the dealing for IETF 88 and when the tooling is stable will also move to the xml2rfc SVN so more people can collaborate on filling out the process to fill out the vocabulary

Julian will turn out the draft, but it is being driven from the the relaxNG file, but that file does not have the prose explaining what the pieces are; could we capture the prose in the relaxNG file?  Yes, probably, but not sure if that's the best approach3. Drafting the I-D to capture all of this -> website not draft   a. where to put sample publication formats?    

b. I-D to be drafted for group discussion by 16 October
RSE Wiki Archive

User Tools

Site Tools

Page Tools
