RSE Wiki Archive

User Tools

Site Tools

Trace:
design:20140806-notes

Differences

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

Link to this comparison view

— design:20140806-notes [2014/08/19 08:56] (current)
rsewikiadmin created
Line 1: Line 1:
  
 +Probable regrets:
 +Julian
 +
 +Attendees:
 +Heather, Joe, Robert, Nevil, Paul, Tony
 +
 +Agenda
 +0. Administrivia
 +  * retrying doodle poll
 +
 +1. Doc status/review
 +  * XML v2
 +no update; fairly stable in the repo; Julian is intending to pull out any examples in there, and point to the to-be-drafted examples draft
 +
 +  * XML v3
 +Paul: no new changes; the big pending thing is possibly redoing the tables, and that needs to be done on the list with Julian, Joe, and Paul hashing out a way forward (abandon text table? leave it in? deprecate it in v3?)
 +
 +  * HTML 
 +HF has a question still open to the team; need to make sure I have the id= info correct so I can finish updating the draft and getting it posted.  
 +
 +Joe said on the list: "I think we had said that the id would go on one of the <a> tags, rather than doing two divs.”  Joe’s recollection is we had talked about having the generated id on the div’s, and the author supplied one on the <a>.
 +
 +Paul: for headings or sections, the <h> tags and the <a> tags are the same.  Remember discussing this, but don’t remember the conclusion.  
 +
 +Joe: let’s all re-read the thread, rather than discuss on the call
 +
 +Paul: the div is enclosing the whole thing, and we will have two id’s, and so having them be parallel was a good thing.  Joe and Julian’s argument, though is that It’s not the finding that matters, it’s what the browser does.  If we are always going to have a second div, even without an author supplied id, that looks weird.  If we are always going to have a div, the CSS will look weird, and you’ll never be sure if there is one or two div
 +
 +Paul: we will always have a div for an author generated id, but the open question is whether or not we have a second div, and if we do, do we _always_ do.
 +
 +Tony: may not have a div, but you could have a span.  cref could be another thing that would require an anchor.
 +Paul: is there ever a call for a second div or span to hold the author anchor?  Possibly no, lets only have one div or span
 +
 +Joe: that is my strong preference, unless there is a better argument
 +
 +Tony: why not just say there will always be a div or span that’s auto generated, but if the author provides one, allow it.  Joe: because that makes the CSS weird because you don’t know how many levels of nesting you have.
 +Paul: is there any other reason for adding the second div or span?  Tony: no, and if there is another element that can hold it, fine with that, too.
 +
 +Paul: then I would say then, since all anchors come from an element within XML, we always have (?) — if we can get away with only having one surrounding, that will be great, and fix the outlier cases  **Work Item for Paul to look at where we generate anchors.  Suggest looking at Tony’s email from the 28th.
 +
 +Tony: is a div or span allowed to have two id’s?  No.
 +
 +Paul: I think cref is the only span-level one, so the others will be creating an html tag of some sort that can have an id tag in it
 +
 +Paul/Heather: make sure “this document is a good example” is removed, and identify any TBDs still in section 4
 +
 +  * PDF
 +Tony: been on vacation
 +
 +  * SVG (GenART review due in ~2 weeks)
 +Nevil: one thought occurred to me, that setting the scale to resize the diagram - would it be useful to have a “scale=“ attribute for whatever XML brings in the diagram?  It may not matter either way.
 +
 +Joe: may want to do testing on various devices to see what it looks like.  We should have examples as separate files, running in text, then have people try out their favorite reader.
 +
 +Nevil: I have an example with a pulled in SVG on my home page, and there is a URL to that in the draft.
 +
 +  * plain text
 +HF: no updates made; will come back to this after the framework draft
 +
 +  * framework
 +HF: FYI, also working on a digital preservation policy doc, which is outside the mandate of this team, but it is being spurred by the format work
 +
 +HF: framework draft is coming along, with intro and problem statement drafted, the transition plan sketched out; need to flesh out the description of each doc and how they relate to each other and the work.  Debating whether it would be useful for me to put this (and other) docs I work on in a git repository.  I haven’t gotten the best reactions to my early drafts — people seem to expect more “finished” content, even with -00’s — but I think the transparency has value.  Thoughts?
 +
 +  * examples
 +Paul: this will include much more than the examples being pulled out from v2 and v3; this will kick off when Julian is back from vacation.  This will show people how to do things in whatever version they are using AND to show how things are changing between v2 and v3, to inform a converter on what it should do.
 +
 +Tony: work on the prototype converter will be very useful to inform this draft
 +
 +2. AOB
 +Joe: Sara is still interested in writing an EPUB draft; she hopes to have 
design/20140806-notes.txt · Last modified: 2014/08/19 08:56 by rsewikiadmin

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki