User Tools

Site Tools


design:20150414-notes

Differences

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

Link to this comparison view

design:20150414-notes [2015/04/28 14:05] (current)
rsewikiadmin created
Line 1: Line 1:
 +Attendees: Alice, Julian, Nevil, Paul, Robert, Tony, Heather, Joe
 +
 +0. Agenda bash
 +
 +1. Draft review
 +    - xml2rfc v2 (*ref review complete?)
 +Julian: No progress made yet. Will work on this this weekend.
 +Note: this is holding up Paul a bit as he needs to make changes and discussion on v3
 +
 +    - xml2rfc v3
 +
 +Paul: had a discussion a few weeks ago re: attribute names. We should be consistent. It should be camelcase. The input processor will allow older attribute names, but the output will always be in the documented name.  Any objections?
 +
 +Joe; as long as we have a list of what must get changed and what it gets changed into, that’s ok. It will fee requirements.
 +
 +Paul: how to handle this?
 +
 +Tony: have an annotation when you have a change
 +
 +Julian: it’s just one attribute in question that have a dash? don’t want to touch the attributes that are already all lowercase.
 +
 +Paul: will do a review and make comments in the text.
 +
 +      * svg element
 +Joe: agreeing with Tony and Julian for HTML. The vocabulary should be able to support more than SVG, but the RFC Editor can restrict what they use.  If it’s a src=, then inline; if data:, then pull it out and inline; for all other types that are in the v3 draft that are plain text
 +
 +Paul: what about the v3 spec? 
 +
 +Joe: leave as is.
 +
 +Paul: we don’t define the svg element in the vocabulary; do we need to?
 +
 +Julian: content model of artwork element can currently be only text. If there is something else needed, it would be the svg element and the svg namespace.  ​
 +
 +Joe: sent RNG; 0 or more plain text, or svg element in svg namespace.  ​
 +
 +Julian: delegate the checking the content model with whatever we want to use to check. ​ The SVG draft defines a profile for TinySVG, and that’s what we will need to be checked against. ​ That will be a leaf node for the grammar.
 +
 +Robert: is there a place where we can point people to Nevil’s draft? Yes.
 +
 +Joe to send a correction to the v3 grammar to the list.  Paul will add an svg element, will have some RNG pointing to the proper namespace; also point to Nevil’s SVG document.
 +
 +Nevil: stripped out context URLs from the profile; SVG files should be completely self contained. Just saying it conforms to the draft should be enough; only a filename is required.
 +
 +Julian: agree that we wants to strip those elements, but we shouldn’t strip the namespace elements. All agreed.
 +
 +      * <b> and <i> vs <em> and <​strong>​
 +Paul: we seem to be on consensus on this one; pulled out <b> and <i>.
 +
 +      * content model for v3 lists
 +Paul: we want people to enter a list without being a part of <t>
 +
 +Tony: Just be careful of the consequences
 +
 +Julian: list model in v2 was broken; name and type of lists so we picked up element names from HTML. We should use them as HTML; they are block level elements and should be used outside of <​t>​. ​ For ordered and unordered lists, should net lists in list item elements.
 +
 +Paul: will put this in the draft, asking for a review from design team first. ​ Everywhere you can have <t> you can have a list.
 +
 +    - Examples
 +Text is basically done. Robert and Alice to review current draft.
 +
 +    - HTML
 +Joe: working on this again. Pete and Joe had a kick-off call to discuss the fours steps: 1: come up with a test doc, 2: making sure there are translations for each of the things in the test doc, 3: ensure there is at least one CSS that makes it look like something, 4: make sure that gets written up in the HTML draft. Pete will get 1 and 4, Joe will get 2 and 3.
 +
 +Robert: timeline?  ​
 +
 +Joe: it’s a week or two of work, but it depends on team availability.
 +
 +    - CSS
 +Joe’s CSS is an existence proof, while this CSS requirements draft are the actual requirements. Will be able to take the prototype CSS as inputs into that. That will say the sorts of things that require styling.
 +
 +    - PDF
 +Draft is basically done. Still some detail to fill out that are dependent on the HTML and CSS drafts.
 +
 +    - non ASCII
 +
 +
 +2. AOB
  
design/20150414-notes.txt · Last modified: 2015/04/28 14:05 by rsewikiadmin