- From: Ian Jacobs <ij@w3.org>
- Date: Tue, 15 Aug 2000 19:00:10 -0400
- To: spec-prod@w3.org
Hello, I've posted a first revision of the minutes [1] on the Web and included them as text below (including action items, without URIs explicit). Please also refer to the IRC log [2]. Comments and corrections welcome. Thank you all very much for attending and for accepting action items so that we will be able to advance. I look foward to more discussion on this list. Best regards, - Ian [1] http://www.w3.org/2000/08/15-spec-prod [2] http://www.w3.org/2000/08/15-spec-prod-irc -- Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs Tel: +1 831 457-2842 Cell: +1 917 450-8783 Minutes of 15 August 2000 Spec production teleconference [1]Discussion | [2]Summary of action items Refer also to: * The [3]meeting announcement on spec-prod. (and [4]belated announcement on chairs). * The public [5]IRC log of the meeting. There is no next meeting scheduled; discussion will take place on the [6]spec-prod list ([7]archive). Deadline for action items is 12 September. Scribe Note: Some of the links on this page are to Member-only information. Participants Janet Daly, Max Froumentin, Paul Grosso, Max Froumentin, Eduardo Gutentag, Hugo Haas, Patrick Ion, Ian Jacobs (Chair/Scribe), Susan Lesch, Philippe Le Hégaret, Arnaud Le Hors, Eve Maler, Norm Walsh. Also, Karl Best (briefly). Chair Note: The bridge was full at the beginning of the call as the previous Working Group's teleconference ended. I apologize to those who missed the call because they were not able to join the call during the first few minutes. Discussion Scribe Note: I've organized the minutes according to publication scenarios, not based on the order of comments. Direct publication of XML documents PG: We can distinguish two cases: 1. Publishing XML documents directly with a canonical style sheet. 2. Using XML as a source format for generating other formats, and not requiring that the source XML be readily publishable with a canonical style sheet. PG: Documentation of processes and policies for naming, content negotiation, etc. when publishing html generated from xml, or when publishing xml directly. (Some issues that arose during publication of XML 1.0 second edition). Tools people are using For validation: The [8]W3C "comma tools" (for validation of HTML, CSS, link checking, etc.) For generation of html from an xml or xhtml source: + DOM WG: DOM scripts (in Java) for generating html, chunking. Refer to [9]DOM Editors notes for details. + WAI WGs, HTML 4, CSS 2: Perl scripts. These are undocumented (hence this whole project!). + Other WGs: XSLT style sheet (refer to [10]XMLspec Processing Applications). + [11]xalan (java tool for transforming XML documents into HTML, text, or other XML document types). EM: Do people expect to continue to author in xhtml and convert each time to XMLSpec, or to convert once to XMLspec and continue from there? Conversion strategies will differ depending on what your goals are in this regard. I recommend optimizing for one-time conversion. For PDF/PS generation + WAI WGs: html2ps, ps2pdf + MathML: xslt to produce TeX, then PDFTeX. + [12]FOP (XSL FO to PDF), [13]PassiveTeX (XSL to PDF through TeX), [14]Epic, tool from Oracle. MF: I'm working on tools to generate XSL FO's from XMLSpec. I've had some problems getting FOP (XSL FOs to PDF) to work on documents larger than 10 pages. NW: There are ways to increase the memory limits. + Adobe distiller ALH: We should focus on generating PDF. Then you get PS for free. For text generation: Lynx, Netscape. For editing: [15]Epic, [16]xed (NW to make Linux port available soon), emacs, etc. Scribe Note: The previous list has been gleaned from the IRC log and does not constitute produce endorsement. Tools people want * EG: I want a visual xsl editor. * EM: Canonical TR style sheet for XMLSpec * One-stop validation, link checking, etc. for w3c editors. Other issues raised: * Exensibility of XMLSpec v. process for incorporating features into the core. IJ: Dan Connolly does not want a centrally managed DTDs. Use schemas. PLH: I'd prefer not to have extensibility, but would like a formal process for getting something in the DTD. EM: I think that in general people will want to extend the DTD for their specific needs. NW: The reasonable way forward is to approach this as a parallel standardization: have a core DTD + style sheet. When you want to propose an extension, some group reviews the proposal and helps them extend it for their needs. PG: I'd rather people avoid extending where possible. If they're using XML as a database (case a above), that's one thing. But if they're using XML to publish directly, then avoid extensions. EM: A single XML DTD will help people meet W3C [17]publication rules. Do you prefer "late binding" (everyone can do what they want as long as they meet pubrules) or "early binding" (if you start with XMLSpec or some other tool provided by the W3C Comm team, you will get a lot for free). * There was a small amount of discussion about coordination with other groups (Oasis, IETF) at least for the purposes of constructive input and possibly for coordinating a core set of reusable tools. * Chunking and single documents, online and offline reading. Summary of Action items Results of all actions to be sent to [18]spec-prod. Deadline for all action items: 12 September 2000. * EM: Propose harmonized version of various XMLspec DTDs in use by different WGs. Issue: What should the core be? E.g., should it include possibilities for DOM APIs since more than DOM WG are developing these APIs? * NW: Propose canonical style sheet for publishing XMLspec documents as W3C technical reports, based on various style sheets in development independently. HH and NW will work together to ensure the unified style sheet available in CVS. Please send your style sheets to Norm at spec-prod. * IJ: Update "[19]How to Release a W3C Technical Report" with more information about XML processing. Clean up since some information redundant with respect to [20]publication rules. Include reference to comma tools. IJ: Those present unanimously agreed that information about publication tools should be public. ISSUE: spec-prod is public and so should be any home page for information to editors. How to release a W3C tech report is Member-only. * JD: Talk to W3C management about securing resources for ongoing tracking, development, and promotion of publication tools. * EM and IJ: Encourage participation on spec-prod by other W3C editors (e.g., by sending email to chairs).
Received on Tuesday, 15 August 2000 19:00:16 UTC