Attendees: Alice, Joe, Paul, Tony, Julian, Nevil, Heather, Robert
0. Agenda bash
1. Format SoWs out for community comment
- FYI, they’re out there. No comments returned yet.
Paul: some people are looking at them because Paul is getting strange questions.
2. Draft review - xml2rfc v2 (*ref review complete?) Julian: No update yet. Will try for next weekend.
- xml2rfc v3 So much discussion on rfc-interest, anything resulting in changes? One thing.
Paul: formatters that are going to paginate should try not to break artwork, source code, or tables across page boundaries. That’s the only high level thing from anything the list that is actionable. Julian doesn’t agree in Paul’s proposal. Will discuss under agenda item 3 and/or on the list.
Tony: the PDF doc has similar words about keeping artwork, etc, together. Maybe the wording should be in the rendering docs rather than the v3 document? Julian agrees; anything that has to do with pagination is wrong to have in the vocabulary document.
Paul: there are two different thing that will do pagination; our tools and community tools (including print function in the browser) and so thought a mention in the vocab doc was reasonable.
Paul: has a note about xml:base, which we talked about a few weeks ago wrt xinclude, but needs a reminder on that topic.
Julian: what we discussed was that as xml:base can be something that can be a result of xinclude processing, whether we should consider documents with xml:base attribute to be valid or not? IF yes, need to include in the grammar, if not, need to put in prose that xml:base attributes will be stripped out (which in practice shouldn’t be a problem). Someone pointed out that in some cases this attribute might be interesting and something to keep; it can allow to refresh a document with refreshed includes (so we know where inclusions came from); could be useful for reference handling.
Joe: we ought to include it, but it shouldn't be mandatory and can be included anywhere we use xinclude.
Paul: so it would have to go in the grammar everywhere?
Julian: we never say that a document has to be valid according to the RNG. Maybe ay “document after stripping xml:base has to be valid according to the grammar.
Joe: do we allow xml:lang? Address elements and author information (?) so that would be a reason to put it in. Aren’t there a bunch of xml: attributes that are always in scope?
Julian: we are at the point where it would be useful if the tool to generate the spec knew about global attributes. Attributes that are allowed everywhere so we don’t have to repeat them throughout the spec.
Paul: would xml:lang also become a global attribute?
Julian: may be easier to have it everywhere
Joe: could we say xml: is global? Yes, but we don’t know what the W3C defines as xml: attributes, and xml:id wouldn’t itself make sense.
Paul: we are deprecating xml:space in a few places, so no, an xml: shouldn’t be global. Let’s keep a short list of ones that we know (space and lang). Can we say this in prose? Is there a way to put them in one place that becomes universal in the RNG?
Julian: can define a group of attributes and then reference them in every element, but that would require something additional in every element definition.
Paul: Maybe do this just in prose, then, not in the RNG itself. (Julian and Joe are ok with that, if no way to put gracefully in the grammar)
Tony: does this effective man two versions of the grammar, one that people need to read, and some that people can just use?
Paul: the prose rule would need to be known by the validator.
Julian: related discussion about pagination - we talked about extension points and allowing foreign name space attributes to let people experiment. That has similar implications on the grammar as the rules in prose in terms of rules for the validator.
Paul: Yes, it’s about anything where we want people to be creative. We will have a list of elements, in prose, that says “anything in this list is considered valid, and there may be other things on this list that may be valid later, then a validator for this needs to strip first.” we can then extend that and the RFC Ed would need to keep a page with all of these.
Joe: this will probably work, a little uncomfortable. Like when we can add stuff without breaking existing stuff. Can we have a rule that says “ignore what you don’t understand”? Julian will investigate.
Julian: if we have to put in each element of the RNG, it wouldn’t be too bad if we updated the code that generates the specification to know about these things and won’t repeat them all over. So, xml:base would be allowed in each element, but wouldn’t show up in the attribute list.
Paul: but that takes us back to the two versions of the vocabulary - the printed one and the actual one. Might make the RNG unreadable.
Joe: This is about adding at least two to each element. Let’s at least give it a shot.
Paul to start writing something up, Julian to do some further research, and then we’ll take it to the community to help address things extensions (like pagination).
Paul: Prohibit foreign elements and ignore foreign attributes.
Joe: prefers ignoring as much as possible.
Julian: agree with the rule, but that’s hard to express in the grammar.
Paul: Maybe we really do have two things, the actual grammar that’s unreadable and our grammar with some prose.
Tony: does RelaxNG allow macros? Where you could define a common macro?
Joe: there are some capabilities in this space that might meet that design concept. It’s not called “macro” but maybe reuse, or subclass, or something along those lines.
Julian: tagging ABNF might be another extension.
- HTML No time so far. Next step is to match it to v3 and make sure we have everything. It’s a fairly mechanical set of next steps. Joe has prototype converter code he could hand off. HF to ask mnot if he might have time, or maybe matt miller. Paul to ask Tim Bray who would also be good but who probably doesn’t have cycles.
- Examples No updates since last phone call. Ready to throw in more examples when Tony is back up and running. Will make progress in the next two weeks.
- nonascii
3. Pagination - anything further to discuss? Note that the RPC has indicated some concern about a possible increase of multi-page tables and figures, and so would find hints from the authors more helpful.
Paul: believe we have new people who really wants pagination. He doesn’t seem to have been paying attention overall to the conversation. Would like to figure out for our documents, when we are doing artwork, sourcecode, or tables, what is the reasoning that we don’t say “just leave them on a page unless they are multipage”.
Tony: the text with “keep with next” and “keep with pre” if you have that same text with artwork and tables, it would make Tony happy.
Paul: proposing that wording be apply to the element itself, not add an attribute.
Tony: happy with that.
Paul: result, paginated output of things that have longer artwork, sourcecode, and tables, will have a third of the pages with a lot of whitespace at the bottom. But there would be no question “did something get broken across a page boundary.“
Tony: that’s what current xml2rfc does now - tries to keep it all on one page.
Julian: People keep complaining about page breaks and artwork because it makes things ugly, but the issue here is that once we move to the new canonical format, there will be no ambiguity because you can look at that format and clarify what the intent was. In looking at what we put in artwork today, see quite a lot of examples where it is ok to break the artwork on an empty line; it depends on what the artwork contains. Heuristics are a good thing as long as they don’t break anything.
Paul: the simplest thing is to not break ever. The expense of that is low, which is that if you are scrolling through a paginated thing, you might have to scroll more often. Or if you have printed it to paper, you may use more paper. So this can be even simpler.
Julian: what do we want to simplify - the formatter, or the amount of things you need to think of when you write your text in order to get the processor to do the right thing with it.
Paul: Almost always worse to break a flow diagram across page.
Julian: other thigns we can do - we relaxed figure to include multiple artwork elements, so we can possibly use that to break between the distinct artwork elements. For tables, if you have multipage tables, why would that be a problem?
Paul: some tables will have headings, and some won’t. Tables with headings may read as two separate tables when displaying across pages.
Joe: if it was two tables, should be labelled as two tables.
Julian: if the developer decides to never break in a table, that’s fine, not ok for our specs to require it.
Robert: Possible use case: what about the situation where you’re working on a mime definition doc, and you specifically want to talk about the separator “blank line” having a break at that line would be devastating.
Joe: thought we were talking about tables not examples (figures or artwork). Second, thought putting some background color on an example would help this quite a bit.
Julian: background of artwork doesn’t need to look the same as a blank line; it could be a line in a box with a light yellow background.
Alice: the aspect from the RPC perspective - if you know there is a good place to put a page break in the doc, then how can the author provide that indication? Assuming that when there is an HTMl output, people will do bigger tables and fancier things. Also, seeing more more than one page tables becoming more common now.
Paul: We’re ganging a few things here. Artwork, which is raw text, and source code, which is raw text, you can’t put in hidden attributes. You can add those in tables.
Julian: we already have the ability to have subsequence art elements, If the choice would be to make the grouping explicit instead of the breaking points explicitly, the grouping would be better.
Joe: could imagine a sub element of artwork being “this is a chunk you should never break” The v3 spec currently have figure containing at least one artwork or source code, so we’re already in good shape as it stands by just saying “don’t paginate in one of those” and if more than one page, make it more than one artwork or sourcecode.
Julian: this is the right solution for artwork and sourcecode, not sure about tables.
Joe: tables have ability to have headings repeated across multiple pages, and will be labelled things like “table 1” and “table 2”. Remove the restriction on table, and if it’s a problem, come back and deal with it. Don’t specify it for the processor.
Paul will remove the pagination wording for tables; keep what he has for artwork and tables.
4. AOB No call 3 March 2015
