This is an old revision of the document!
1. Status of draft-reschke-xml2rfc-latest
Julian is focused on httpbis right now; hope to have that done in the next week and then will focus more on this draft. The remaining text must have someones(s) research what really happens in order to describe it in the text. Can look at the old spec regarding what was said and have that drive what the text might say. What kind of metrics make sense? Where should we duplicate, document, or have it do something else.HF: reach out to people on xml2rfc (esp. Julian) to get help in some of the missing descriptions
Does the documentation cover the type of output (text, list, other?) - it is supposed to be a vocabulary definition, not a description of what a processor will do with it. A processor will usually try to do something based on listing, but we don't want to document the algorithm for picking the symbols.
One draft or two? Ultimately, probably should be two, though for initial discussions having it all in one place is useful to some.
2. Review current content of the “New or modified XML syntax” to determine what we want in v3 of the DTD - https://www.rfc-editor.org/rse/wiki/doku.php?id=design:xml-tags
Paul is adding about 5 or 6 issues a week to rfc-interest and getting a reasonable amount of discussion. The things discussed so far are incremental changes to what we have so far; haven't started talking about the bigger changes like artwork and tables. Paul will continue nudging the conversation on rfc-interest, and will hold the pen on the v3. Do we want the v3 doc to be a diff of v2 (normative reference) or a self-contained doc?
Paul to get reasonably full text in 3 weeks, then starting with the rng and small diffs and proposal for artwork would be sufficient to do a first draft, and then Paul can start pulling things in and/or link the two docs more effectively. Julian will fork the doc in svn in the next week, and Paul will get something started before the next call.
HF: Drop a note to the WG chairs mailing list to ask them to ask their authors to think about XML vocabulary and DTD and what would make life easier for them.
3. PDF requirements (review messages on rfc-design posted 30-Dec-2013)
PDF language has many similarities to HTML and can carry that along as semantic information. There is likely a fairly straightforward mapping from generating the HTML to generating the tagged PDF. Tony to work on a first cut at that mapping.
IF PDF converters already exist, and specifically make PDF/A-1a, is there really a task for us? Can we rely on existing converters? It is very important for us to understand the tags so we have criteria for evaluating converters. These tags come in to play in bookmarking.
Concern that we're really going beyond what's needed - do we really need the ability for PDFs to be more than rich printing? Even the marking up of it with tags is still like printing and adding stickers - this doesn't need internal tagging. Markup doesn't require PDF/A. We aren't sure that PDF/A-1a will actually work for the mark up tools that some folks use - this may create more problems. Since PDF/A-1 is just the old PDF 1.4 there _shouldn't_ be a problem, but we probably need more testing.
If we provided a PDF with features, it likely would get used for faster indexing, esp. to images.
Julian looked in to this about 3 years ago, and the only open source tool that helps in producing these is FOP, and it didn't have PDF/A (might have it in limited ways now).
4. (added) Requirements draft - who holds the pen? Joe.
5. SVG Feedback on list is very much appreciated. Draft underway. Suggest that Nevil not take an overly strong stance on color. Starting with black and white makes sense, but long term that could change. Would like to try a few more kinds of diagrams to see if we can narrow in on a specific metalanguage that could cover 70-80% of the cases. Dave suggests looking at sequence diagrams, something that represents a state machine, and a topology diagram. Joe agrees; for state machine, graphviz does a good job at generating these. That's how Joe generated the example in draft-html-hildebrand
Paul to send an example of a ladder diagram that would be difficult for any tool to do.
Did you identify a place in SVG where this metalanguage could be described? the tsp element, which could go almost anywhere, could potentially include that. What do existing readers do with that? Not sure yet. Can we do some of this with the object tag in HTML? Do we want descriptions or outside? Browsers that don't have SVG capability will need it outside. Metalanguage could be the alt text, which in turn would feed the generation of the SVG when necessary. It might want to be in the SVG as well, when reading the plain text document would be more informative than reading HTML, and when they hit SVG, they download it. If you do metalanguage on the outside, they'll never hear the it when they download the SVG as a standalone thing. Both spots may be the right answer to respond to the largest number of use cases. How we do that can be a programming exercise.
HF needs to make sure to be querying the correct community for input. Sam at least would rather good HTML with markup than text. What helped for him is being able to jump within a document according to heading.
