RSE Wiki Archive

User Tools

Site Tools

Trace:
design:20140819-notes

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

— design:20140819-notes [2014/08/19 16:10] (current)
rsewikiadmin created
Line 1: Line 1:
  
 +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 
design/20140819-notes.txt · Last modified: 2014/08/19 16:10 by rsewikiadmin

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki