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

0. Agenda bash

1. Draft status and expected timeline for "done enough to kick off the SoWs"
   * v2 draft
no update

   * v3 draft
Paul: want people to think about the question of tables; we should have real tables, possibly using the HTML table model.  We can’t really have v2 tables and v3 tables at the same time; v2 tables in a v3 doc will look bad, will hold on to code that knows about width of page; but we can’t also just drop v2 tables because a lot of people use them for things like IANA considerations.  If we adopt the idea that v3 is going to have new, useful tables (i.e., basic HTML tables with table rows, table items), we are are going to need to have the v2 to v3 converter will need to convert tables, which will be technically difficult.

Tony: how different are the models?

Paul: not horribly different, but somewhat different.  We have a not-great fallback; for people using the v2 tables to get structured ASCII art, the v2 to v3 converter can put out what the v2 output was and stick it in a figure.  The v2 converter could v2 over the table and get the output and put it as a comment in the v3 output, at which point the author who will have to review can decide what to do.  This will probably upset people.  

Tony: have not seen a description of the v3 table; Paul: we had talked on the phone about using the HTML table model, so as not to invent our own and taking a subset of the HTML, maybe 6-7 tags

RjS: remind me of the v2 table construct? its a text table and ttcall and so on

Paul: does the RPC ever insert v2 text table stuff? Alice: not really; that would be a very weird, rare case. In theory, in the future, would the RPC want to switch the old tables to the new table elements?  Would that be an RPC clean up activity?  Paul: it could go either way; it might be too late and introduce semantic changes during AUTH48

Paul will send something to the list as a proposal

   * examples draft
started a very bare one, but may have a draft something go the list by the next call

   * SVG draft
no update from GenART; HF to ask for status

   * plain text draft
Heather: updated to include page layout info, asked Sandy and Alice to review

   * PDF draft
Tony: had a meeting last week on the draft, and another update should be published soon; need to gather more information on implementation (what’s out there) that could support this format; contributions gratefully received

Paul: would this PDF format be the same as the archival/legal format HF has talked about?

Tony: there is no one tool that does everything very well; if we want the tool chain that is built on top of the python code we already have, the python libraries are less good at things like embedding and digital signatures than other things.  What we might wind up needing is a set of tools that can be used by the authors, then a final step in the process that adds the final signature and embeds the XML.

Paul: since HF wants to restrict to PDF/A, will that restrict the features like internal links and inlined SVG?  Tony: no, just the opposite.  Because we’re going in A-3, those things are mandated to be supported.  Paul: used to the A-1 discussions from long ago.  Tony: A-3 is based on features from Adobe 1.7 (the PDF that most of us are familiar with).  Paul: great.

   * HTML draft
HF: are we anywhere close to making a decision?

Paul: there are different opinions about where 

Joe: the question is still the number of divs; still a question about when do you think the authors supplied id= would be used for selecting the content form a particular section, rather than jumping to that section

Julian: if you write a script that expects a particular section

Joe: but that would use the autogen ones because they will be iterating through all the sections

Julian: I am thinking of tools that says to look for particular sections; don’t see a difference between these two

Joe: we want multiple id for the same div, but the limit is the HTML itself.  You’re going to get different answers if you have nested div.

Paul: can see where after we’ve done this for a year, people who are writing RFCs will not differentiate between autogen and author gen id’s. If there is an action difference, it will be eventually be seen as a bug.  The reason why some people like to name things is so that name lasts across multiple iteration of a draft.

Joe: get that, but don’t get that as part of a div

Paul: example: “ABNF is here”

RjS: asking about this thing; thought we had a different tool about identifying a chunk that is ABNF?  Yes, we do.  

Paul: we could say if you point at a section, you will not get the contents of the section; if you want the chunk, make it a figure

Joe: this is entirely esoteric

Paul: we can say no id will extract a whole section for you.

RjS: specific use case - have a browser, looking a doc that is referencing security considerations of another doc, do I want the ability to pop up the security considerations from that other doc?  Paul: would say no, but I link to.  Joe: only ever link to author-supplied one.  
Tony: are we pointing at a chunk or a location?

RjS: if you are pointing to a location, you have to go to the whole doc; if are pointing of at a chunk, then could get just that chunk.  This wouldn’t be done via HTTP, but something like javascript.

Paul: how do we want people to be able to use these id’s.

Julian: not sure that’s my opinion, but we can ask why we want t micromanage the HTMl to that level of detail, and instead leave it to the developer.

Joe: that’s just punting the problem down the road; we should fix it

Paul: take this as an action item to reinvigorate the discussion; do we have a picture of what an id= is supposed to point to, and are id= for section for other id= such as those for figures

Tony: we’re back to trying to understand what requirements we’re trying to resolve.  It’s hard to answer the questions otherwise.

Paul: this also ties back to the PDF question.  Are author ids going to have any validity in the PDF? will there be automatically generated section numbers?  Julian: the answer for the PDF should be the same as the HTML.  It is all possible.

Tony: internally, PDF has evolved to become very HTML-ish

Julian: URI provided = http://greenbytes.de/tech/webdav/rfc2616.pdf#GET

   * framework draft
HF:  should each section on the specific drafts highlight the major issues and associated resolutions?  Too much detail?

Paul: yes, too much detail

HF: what about the digital preservation considerations?  That work was spurred by the format work, though it isn’t quite in the same bucket of stuff.  Have it here or no?

Paul: No; IMHO you already tie the two topics more closely together than you should

HF: Since I’m not sure it belongs here either, will pull out.  Expect a draft later this week that will ask for input on what’s needed before releasing to the community as a -00 draft.

2. AOB

Julian: status of style guide? HF: we’re working on a landing page that explains what changes are pending tool updates, then linking to the RFC
RSE Wiki Archive

User Tools

Site Tools

Page Tools
