This shows you the differences between two versions of the page.
— |
design:20140129-notes [2014/02/06 08:02] (current) rsewikiadmin created |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | Attending: | ||
+ | Heather, Paul, Julian, Alice, Tony, Nevil, Adam (drop off a few minutes early), Robert, Dave | ||
+ | |||
+ | Apologies: | ||
+ | Ted,Joe | ||
+ | |||
+ | |||
+ | 1. v3 vocabulary update | ||
+ | * encourage backward compatibility or no? | ||
+ | * any specific questions from Paul or requests for focus on certain areas? | ||
+ | |||
+ | Paul's perspective - there will be a good tool, there is no expectation that v3 is going to be the required submission format any time soon, the intention that starting a v3 doc should be easier than a v2 document. | ||
+ | |||
+ | The implicit part of that is that we can make breaking changes if those breakages will make things easier to start, edit, or add new semantics. | ||
+ | |||
+ | Julian - are we talking about changes that would break a v2 processor, or breaking v2 documents that would be processed by a v3 processor. | ||
+ | |||
+ | Going back one step - a v2 document breaking under a v3 processor. | ||
+ | |||
+ | The concrete example is lists that look just like HTML (see rfc-interest thread). | ||
+ | |||
+ | The biggest difference that inside, whether it is ol or list style=ol, we currently have t's, but then we have t but not really t if we don't have a new bullet. | ||
+ | |||
+ | Julian looked at the HTML in more detail today, and they have a similar challenge they solve with a list item element which takes inline text or paragraphs. | ||
+ | |||
+ | Robert - back in the day of when he wrote really big documents, can't see this is going to be as simple as Paul suggests in doing an automated + manual conversion. | ||
+ | |||
+ | Julian - conversion probably won't be that hard, but if we change things unnecessarily, | ||
+ | |||
+ | Heather - there must be a middle ground of allowing changes but halting gratuitous changes. | ||
+ | |||
+ | Robert - doesn' | ||
+ | A position of we will work hard to maintain backward compatibility and you will have to argue hard against that makes sense. | ||
+ | |||
+ | Paul - if we say you can propose breaking ideas and we will discuss, that's fine. But don't want to say "you are proposing a breaking change, so we'll do something else instead to try and avoid the breaking change" | ||
+ | |||
+ | Tony - **would rather encourage backward compatibility but not be constrained by it**. | ||
+ | |||
+ | Julian - one lesson from the HTML evolution, if you have a successful markup vocabulary, you try to avoid versioning with this kind of vocabulary. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | 2. SVG profile update | ||
+ | * Nevil to talk about his draft - any specific questions or requests for focus on certain areas? | ||
+ | * note that I don't think the IESG, must less the community, have actually come to consensus on " | ||
+ | |||
+ | All Nevil has done so far is make an xml2rfc version of what he's said on the calls. | ||
+ | |||
+ | Alice: is there any example where an author has wanted to do something like that? | ||
+ | |||
+ | Nevil: not as far as he knows; this came out of reading the W3C docs. | ||
+ | |||
+ | Paul: in a protocol flow diagram, when you hit another layer, someone would turn that into a link or anchor to another RFC. | ||
+ | |||
+ | Julian: if we have complex documents, we should not make it impossible to have links between these documents. | ||
+ | |||
+ | Robert: how is this different that providing a URL in a reference? | ||
+ | |||
+ | Nevil: it is the same, but we already have problems with stability of references. | ||
+ | |||
+ | Robert: but we do allow them, and we do apply judgement as to whether those links are stable. | ||
+ | |||
+ | Nevil: then the RFC Ed team would have to check these things within drawings. | ||
+ | |||
+ | Paul: maybe say links are allowed but only to anchors to other points in the document, and with the exception that you could add a fragment component? | ||
+ | |||
+ | Nevil - still intends an appendix with element names and attributes allowed. | ||
+ | |||
+ | One other open question - tools like Inkscape produce bloated SVG with detail that does not need to be there. | ||
+ | |||
+ | Paul - that tool should also be fairly easy. "If you give me an SVG, I will give you back an SVG with the bad stuff stripped out - is this what you want to see?" | ||
+ | |||
+ | What about normative images? | ||
+ | |||
+ | |||
+ | |||
+ | 3. PDF to HTML mapping | ||
+ | * See Tony's draft - any specific questions or requests to focus on certain areas? | ||
+ | |||
+ | There are obviously a bunch of holes in it, many place holders. | ||
+ | |||
+ | |||
+ | |||
+ | 4. IETF 89 | ||
+ | I know we will have a BoF, don't have date/time yet. BoF will be both " | ||
+ | |||
+ | |||
+ | |||
+ | I am concerned about the requirements draft for HTML - haven' | ||
+ | |||
+ | |||
+ | |||
+ | AOB | ||
+ | |||
+ | One of the things that would be useful for people to think about (not just the Design Team) is what the RFC Editor Info Page will be structured. | ||
+ | |||
+ | If we have a date or an RFC number for cut over, Julian would wish that old RFC will serve as txt, and new RFC will be served as HTML to the web browser, with a URI that does not contain a file extension. | ||
+ | |||
+ | For Paul, if calling RFC7500, would want the info page. | ||
+ | This discussion should definitely happen, and would be useful to get people thinking. | ||
+ | |||
+ | Robert - thought we were talking about going ahead to create an example, a prototype of the canonical formats and the derived formats, the mockups and the differences you will see between the things. | ||
+ | |||
+ | What is the canonical URL, and what do you get when you resolve it. Doing a mockup with that will be useful. Maybe think about this in the Toronto timeframe. | ||
+ | |||
+ | Something to consider - one of the things we have wrestled with re: tool, etc, was to make this a decision that a user could influence with a cookie. |