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.

Attending:
Heather, Sandy, Tony, Paul, Nevil, Julian

Apologies:
Robert, Adam, Dave, Ted, Joe

0. Agenda bash

1. XML v3 draft
  * inline text as <code>
"Unless he was asking for a new feature in the XML format, namely marking up an inline span of text as "code”.  In which case (particularly since I also would like that feature), we ought to make sure we've thought it through a little more." -- Joe

Julian: We already have a way to mark up something to be monospaced in open text.  Another aspect is control over whitespace.  If we mark up symbolic names, it would be nice if it wouldn’t only effect the text style, but also enable us to do more things like consistency checks and automatic linking of things.

Paul: some of what you mentioned might also be useful outside of code.  If we’re going to add attributes to elements for running text, we should add them to all of them.  

Julian: I support doing this, and this can be done, but we need some research on how to do it best. 

Paul: this would be a set of features for a small set of authors.  This could all be new attributes in current tags, possibly changing <tt> to mean more than just typewriter font.

**Julian and/or Joe need to come up with concrete proposals on what we want done and how to do it, and we bash from there.**

  * any further discussion on tables

In the current draft, very purposefully has it that a table always has a caption, which is not true for figures.  The reason a table might need a caption is that we will try to put pilcrows everywhere.  there isn’t an obvious/sensible way of doing this in a table that has rows and columns, but there is an easy way to do that if there is a caption.  

How is this diff from a figure?  A figure that is not a table can have a pilcrow added to its right.

**Julian: if Julian can demonstrate that a caption is not required for a table, then we don’t need to make tables different from figures. If Julian can’t do this, would prefer to be have to figure out a link to a table rather than have authors come up with captions for tables so there can be easy links. ** 

Paul: figures and tables can have captions with no names, and things will work fine.  

Paul: **Wants design team to esp. look at description of tables and comment on rfc-interest.**  Note that preamble and post amble have been removed because they really are the same as paragraphs, but others may disagree.  

Tony: not sure how common post and preambles are in existing documents.  And they are not identical to regular paragraphs because they follow different alignment rules.  

Julian: not sure they do in practice?  When I write drafts, I frequently flip between using preambles and just using a regular paragraph in front of a figure, and don’t think in the current tools it makes a visible difference.  If we keep them, they will effect paragraph numbering.  If things look like a paragraph in the output, but don’t look like paragraph in the input, things will look odd in the numbering.

Paul: from a semantic point of view, don’t see them in typical publishing at all as a semantic difference, so explaining this to an author will be unnecessarily complicated.

Tony: looking at the HTML spec, tfoot happens after thead.  Don’t know if we need to follow that in XML or not.  Paul: I see that, and will swap that.

Julian: tfoot can follow thead, but it an also come before; it doesn’t matter as long as there is just the one.  Paul: ok, will leave alone unless the spec is inconsistent.

2. Examples draft

Tony and Paul talked about this yesterday.  Should have a -00 out next week.  Our current thought is that we’ll have a basic example in v2 of the way you would write a short RFC that also has some other stuff in it, like one of each kind of list, so someone could look at that and see the order, and then the v3 equivalent of that (not sure if that will be hand or machine generated).  The idea is to get the main part of the doc as this one example, then there will also be other sections in future revisions of other interesting stuff such as all of the weird attributes on lists, blockquote, and other things new in v3.  Will probably take a while to finish the whole thing as people request more examples.  But since this isn’t normative, if it gets in the way of something else completing, we can declare “done enough” at any point.  People will want to see the output, which is impossible to put in an RFC because of confusing vertical whitespace.  We want someone to be able to see what the output is, so we can have URL even after its an RFC that point to a stable version of the outputs.  Can point to the tools site while developing, then can discuss whether to move to the rfc-editor site.

Reminder that this is not a tutorial.  This is more for Robert to say to the developers, these are valid examples for future coding.

3. Draft status
  * XML v2 - ready to start the pub process? Yes.
  * HTML

Joe and Paul talked a bit about this this weekend, and he is trying to make sure he understand what the XML to HTML conversion will look like, because the current thought is that the XML to HTML converter should have to create anything new.  It should be able to do direct conversions.  If there are new ids that are needed in HTML, they should be in the v3 document. 

  * PDF

Hope to have something out at the end of the week.   If we have been squeaky clean on the XML for HTML, the same should be true for PDF.

  * SVG

Posted a revised version (-08) mostly in response to the GenART review.  Have also added into section 3 two attributes “role” (because the GenART review noted that ARIA said that would be useful), and “id” which Nevil has found is widely used in constructing SVG.  Those attributes can appear in a long list of elements.  That table should be a good starting point for people writing checkers.  Draft is now considered stable.

  * plain text

-03 posted; biggest change is pagination

  * CSS

4. AOB

Paul:  the v3 document will have some vagueness and holes unless we figure out the relationship with I-Ds.  Since there is a difference between the RFC processor and draft processor that need clarification.  Who will own the processor not being used by the RPC?

Heather: will be discussing this f2f with Jari, Russ, and others next week
RSE Wiki Archive

User Tools

Site Tools

Page Tools
