This shows you the differences between two versions of the page.
— |
design:20150203-notes [2015/02/03 14:08] (current) rsewikiadmin created |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | Attendees: | ||
+ | Alice, Joe, Paul, Tony, Julian, Nevil, Heather, Robert | ||
+ | 0. Agenda bash | ||
+ | |||
+ | 1. Format SoWs out for community comment | ||
+ | * FYI, they’re out there. | ||
+ | |||
+ | 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, | ||
+ | |||
+ | Paul: formatters that are going to paginate should try not to break artwork, source code, or tables across page boundaries. | ||
+ | |||
+ | Tony: the PDF doc has similar words about keeping artwork, etc, together. | ||
+ | |||
+ | 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). | ||
+ | |||
+ | Joe: we ought to include it, but it shouldn' | ||
+ | |||
+ | 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: | ||
+ | |||
+ | Julian: we are at the point where it would be useful if the tool to generate the spec knew about global attributes. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | Joe: this will probably work, a little uncomfortable. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | 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? | ||
+ | |||
+ | Joe: there are some capabilities in this space that might meet that design concept. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | - Examples | ||
+ | No updates since last phone call. Ready to throw in more examples when Tony is back up and running. | ||
+ | |||
+ | - 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. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | Paul: some tables will have headings, and some won’t. | ||
+ | |||
+ | 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” | ||
+ | |||
+ | Joe: thought we were talking about tables not examples (figures or artwork). | ||
+ | |||
+ | 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? | ||
+ | |||
+ | 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. | ||
+ | |||
+ | 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” | ||
+ | |||
+ | 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 |