The DITA Technical Committee met on Tuesday, 8 May 2007 at 08:00am PT (Recorded by Alan Houser ) Agenda: DITA TC Wiki: http://wiki.oasis-open.org/dita/FrontPage 1. Roll call We have quorum. 2. Approve minutes from previous business meeting: * http://www.oasis-open.org/committees/download.php/23914/DITA_TC.5.1.07.txt (1 May 2007) Minutes approved by acclamation. 3. Business: 1. Schedule review (Mary McRae): * start 60-day public review: 5 March * end 60-day public review: 4 May * 7-day comment period before CS vote can launch: 11 May * CS/OS Submission ballot (7 days): 14 - 21 May * OS Submission to TC Administrator: 15 June Discussion: Can we incorporate approved spec changes (non-substantive) into the spec drafts, hold a TC vote, and meet the scheduled start date for CS/OS submission ballots? Action (Don Day) -- Will contact Mary McRae to clarify dates and commitments. (Note from meeting secretary -- Mary McRae, OASIS Manager of TC Administration, joins the call later. This business item is re-visited. See "Return to Item 1. Schedule review" below.) 2. ITEM: Status of remaining 1.1 Spec comments: * Defining and using normative URIs for all DITA-Supplied Schema Components Discussion: How to implement this change? Eric Sirois -- Eliot Kimber, Paul Grosso, and I have been discussing how to identify XML schema and catalogs. Had been using URLs. But apps might try to hit URL if catalog is not available. Current decision is to use URN. Want to approach the TC for approval. PG -- Nervous about doing this in 1.1. Can we work-around and defer to 1.2? EK -- Yes, can identify schema components by file name. No functional breakage if we don’t make this change. PG -- Suggest that we defer this to 1.2. EK -- Currently URIs are published in the spec. EK -- Can continue to use relative paths as we do today. EK -- Want something normative to point to from my shells and specializations. PG -- Only change in the distribution would be the catalog. Would add entries in the catalog that would display the official URN for each module. Would not have to adjust each file. ES -- Would also need to change the spec (currently uses URLs to define shells). EK -- Would need to provide URNs for shells. EK -- Either list URNs for everything or for nothing. DD -- Is this a substantive change? A substantive change requires another review cycle. EK -- Not a substantive change. Names of things don’t affect how people use this. ES -- Remove this information (SDIs and URLs) from the spec? Augment the catalog with URNs. Haven’t changed the files at all. Consensus: Publish catalogs with URNs. Remove the following sections from architectural specification: DTD organization/Public identifiers for DTDs XML Schema organization/XML Schema catalog identifiers EK -- Justification: We can remove these sections because they are incorrect and incomplete. It is sufficient per RFC 3121 to publish identifiers in catalogs. Approved by acclamation. * Missing elements in DITA 1.1 bookmap Chris Kravogal -- and -- want new element Michael Priestley -- Will be making a bunch of changes purely to solve this problem, that we will wish we had not made one release later. Robert Anderson -- Can only accomplish this by specializing . CK -- I concur that we move this to 1.2. TC Concensus: Defer until 1.2. Leverage domain integration capabilities planned for 1.2 release. Can publish best practices for this use case separately from spec. * Clarification requested on collection-type in reltable/relcolspec * minutes do not make clear this is truly closed now DD -- is this truly closed? Paul Grosso -- yes, this is closed. * General scope of Specs (ditaval, metadata) * http://lists.oasis-open.org/archives/dita-comment/200703/msg00001.html Recommendation from public comment to remove reference to ditaval and "profiling" from the 1.1 definitions, abridge 1.1 architecture specification. MP -- I suggest we don’t change the spec. DD -- We need to provide a response. MP -- Proposed response to public comment: "We believe that conditional processing is important so that users can share profiles, as well as source files, for deliverables. Users can exchange profiles, which define the content of deliverables, across applications. We plan to modularize the DITA architectural specification for version 1.2, which will result in a smaller core specification. In addition, we feel that the audience for the DITA architecture specification is broader than public commenter anticipates. Information that the commentor feels is redundant may not be redundant for all readers." TC agrees with Michaels’ summarized response. No change to current spec is indicated. ***Mary McRae joins call**** Return to Item 1. Schedule review: DD to MM -- We have finished public review. Finished last of comment dispositions. Question about interpretation of 7-day comment period before CS launch: We have production work to do before we can take a TC vote. Must we complete the production work before we take a TC vote? MM -- TC can make motion at 15 May meeting to start the ballot. DD -- Can we make motion today? MM -- TC can make motion that as soon as docs are ready, on or after 11 May, can request to start CS verification. MM -- To submit for OASIS standards vote -- must have have 3 statements of use prior to starting that ballot. MM -- As long as ballot starts before 31 May, we will technically meet requirements. MM -- TC can move to submit CS ballot pending preparation of new versions that incorporate TC-approved changes. DD -- We have logged and approved the last of the public comments. MM -- TC can move to submit CS and OS drafts, pending approved non-substantive changes. DD -- Chair moves that we submit current specification, with changes approved today, to submit CS ballot. Rob Frankland seconds TC approves by acclamation. DD -- Chair moves TC administrator to start a ballot to agree to submit the specification to OASIS membership for OASIS standard vote, pending three statements of use. Alan Houser seconds TC approves by acclamation. Don Day to TC -- Please send statements of use for DITA 1.1 to DITA-TC list. MM -- Must come from OASIS organization members. We're looking for something that says "Organization X is successfully using the DITA 1.1 specification in accordance with OASIS policies." A generic statement is better than a specific statement. Meeting adjourned at 9:05 PST