← Prev in month
← Prev in thread
Next in thread →
Next in month →
MEETING MINUTES -- 30 NOV 2004 -- DITA TECHNICAL COMMITTEE
MEETING MINUTES -- 30 Nov 2004 -- DITA TECHNICAL COMMITTEE *** Please see Action Items and Decision Summary at the end *** ** Agenda ** ------------ 0. Request for scribe 1. Roll call 2. Review/approve minutes from 9 November http://lists.oasis-open.org/archives/dita/200411/msg00013.html 3. Specification status 4. List issues (triage as potential post-1.0): - Bugs reported on current DITA DTDs and Schemas - Should <tm> allow images or logoized content? - Should <keyword> be allowed to nest? 5. AOB? ** Minutes ** ------------- 0. Scribe: Michael Priestley (amended by Don Day) 1. Roll call - We have 15 of 19 --> QUORUM - Roll Call to be posted to the TC List separately. - Acknowledged Erik Hixson's Member status as of this meeting 2. Review/approve minutes from 30 November http://lists.oasis-open.org/archives/dita/200411/msg00013.html - We went through the summary of decisions; the action items; the issues to be resolved. - Minutes approved. 3. Specification status - Notes as taken by Michael Priestley: Terminology - Information type - Can we really call a kind of map an information type? I currently think of information type and topic type as synonyms. HICKSON: TYPE USED INCONSISTENTLY SHOULD BE USED ONLY WITH TOPICS, DOCUMENTS, MAPS INFORMATION TYPE REDUNDANT WITH TOPIC TYPE DAY: INFORMATION TYPE HAS EXISTING USAGE HISTORY WITH MINIMALISM HICKSON: CONFUSION GIVEN INFOTYPE AND TOPICTYPE REDUNDANT SYNONYMS MP: MOVE DISCUSSION INTO THE "WHY TOPICS", REMOVE INFO TYPE ELSEWHERE Terminology - Document type declaration shell - This sounds awkward to me - is there a more elegant way to distinguish between the document type in abstract versus the actual file instance of the document type? ESRIG: CONSIDER REMOVING SHELL FROM MODEL, DECLARATION FROM TERM HIXON: DECLARATION IS PROBLEMATIC TERM - REMOVE IT; AND KEEP SCHEMA/DTD SEPARATE - BOTH DESCRIBE DOCUMENT TYPES MP: EXTEND TO MODULES - REMOVE MODULES FROM MODEL LEVEL, REMOVE DECLARATION FROM DECLARATION LEVEL (MODULE ENOUGH) DAY: IS OUR USE OF MODULE DIFFERENT FROM DOCBOOK? MP: TAKEN FROM XHTML USAGE - IS A COMPONENT OF A DOCUMENT TYPE NANCY HARRISON: USAGE IS CONSISTENT (SENT VIA SAMETIME) MP: SUMMARY MODEL LEVEL: REMOVE "MODULE" AND "SHELL" TERMINOLOGY DECLARATION LEVEL: USE "MODULE" AND "SHELL", REMOVE "DECLARATION" PLEASE REVIEW IN NEXT DRAFT Specialization concepts - Introduction to generalization - copying content here from the more complete coverage later on, to act as a placeholder. Maybe rather than have whole topics on generalization, specialization, information types, maps, etc. in the introduction, we could move those topics out to the relevant parts of the spec and slim the intro down to just a definition list, within the terminology section. MP: PROPOSAL TO SLIM DOWN INTRO, CONSOLIDATE INFO IN SPEC SECTIONS, LEAVE INTRO AS SUMMARY Namespace and identifiers - (need to incorporate this) DITA markup - (linking to children not working because children are topicheads - add intro topics for sub-branches) Metadata attributes - audience - Something in that last bit must be wrong. If you define the combination in the topic metadata, why would you need to apply it on a content element. Doesn't it already apply to the entire topic? Wouldn't you want to use a reference or key to apply metadata, anyway? MP: ADD MORE EXPLANATION OF HOW THIS WORKS AND WHY - ATTRIBUTE MAY LIST A SUBSET OF AUDIENCES IN PROLOG; KEY MAY ALSO BE TO DEFINITION SOMEWHERE DAY: ALSO NEED EXPLANATION OF CONDITIONAL PROCESSING: AUDIENCE AS METADATA VERSUS AUDIENCE AS SELECTION ATTRIBUTE DAY: SAME DISCUSSION APPLIES TO PLATFORM AND PRODUCT MP: WILL EXPAND DISCUSSION, CONTRAST AND COMPARE; ALSO ADD TOPIC FOR CONDITIONAL PROCESSING Topics - I'm not sure what the following two lines in the outline have to do with topics. Looks like notes about the DTD structures? Ah, perhaps we need to discuss how the structure relates to the design. (probably okay to delete this comment - just need to clean up outline left from earlier draft) Information types - this usage of information type differs from what we've called out in the terminology section (where it's used to describe maps as well). We need some decisions here. Common DITA map attributes - toc, navtitle, locktitle - navtitle should really be an element for parallelism with the topic metadata. We should consider changing this to a "prototitle" attribute or something similar, for the sake of creating a title only for prototyping purposes. (IE, defining a topic's href and title in the map before it exists, and then creating a skeleton topic from the information in the map). Probably a post-1.0 change, but should discuss. DITA map structure - could add metadata at the row level, and collection-type attributes at the column level, to allow more flexible managament. Post 1.0 Inheritance of attributes and metadata - (extraneous bullet appearing for some reason) Why specialization in content? - (needs beefing up) Class attribute syntax - (should probably move up one level - single children in a TOC are problematic) - to discuss from paul grosso: should we require an ending blank, or is this needless overhead for the specializer since this could be handled by more intelligent checking in the XSLT? My (MPs) thought is that both the DTDs and the XSLT are really outside the domain of the user, and there is a fair chance that a specializer is also writing XSLT or something similar. So the question is not whether we can punt to code, but whether the system of dtd+xslt is simpler with the blank or without the blank - the DTDs and the XSLT are probably being extended/specialized by the same group of people, so we're not saving them grief if we make one simpler at the cost of the other, unless there is indeed a net savings for the system. And in this case, I think the increased complexity of the XSLT match statement syntax - which is already pretty scary - outweighs the decreased complexity of the class attribute syntax. PAUL GROSSO: WOULD BE SAFER FOR PROCESSOR TO HANDLE, BUT PAUL CAN LIVE WITH IT AT LEAST FOR 1.0 BUT WOULD BE NICE IF THERE WERE AN EASIER WAY MP: RAISE AS POST 1.0 CONCERN TO RESUME HERE NEXT WEEK 4. List issues (triage as potential post-1.0): - Not covered. 5. AOB? - Not covered. ** Summary of Decisions ** -------------------------- None necessary this time ** Action Required ** --------------------- 021 JoAnn Hackos, Michael Priestley -- Summarize the discussion of substitution and post to the TC list. Still pending as of 7/20/04. >>>11/30/04: Action: Michael Priestley to add note to conref that people may substitute conref targets at build time 022 Don, Michael -- Put together a "self-study" tutorial/demo, as per JoAnn's comments regarding the DITA sessions. Still pending as of 7/20/04. 036 Shawn Jordan -- Investigate where to point the DITA namespace -- where does the URL point? Maybe an OASIS page that describes what DITA does, etc. Still pending 8/17/04. >>> 11/30/04: Done per previous TC decision on namespaces for 1.0 040 Don -- Cull the past minutes and discussion list to create an inventory of all the things we need to close on in order to create the 1.0 spec. Create a list of these items and post it in the Documents area of the website. >>> This will be ongoing. 051, 055 Don Day, 9/7/04 -- Take the discussion of @scale attribute and related issues to the list (presentation mechanisms). (merge with next...) 059 Don Day, 9/28/04 -- Open a ballot to decide whether to keep the full set of features for mitigating table migration. <<< Closed as of 11/30/04 (decided in previous meeting) *061 Don Day, 10/05/04 -- Reply to image align and tm notes in dita-users. >>> Agenda item for 11/9/04. <<<11/30/04: image align issue is a doc mistake, corrected in the "dita132" toolkit version of Language Reference source. 062 Eric Sirois, 10/05/04 -- provide XSLT validation for specialized schemas once developed (Indi recommends Jarno to work with him) 063 All, 11/02/04, 11/09/04 -- Provide comments to Michael Priestley on the draft -- provide comments to Michael ASAP. Michael Priestley to incorporate comments into draft specification; prepare new iteration for 11/16 meeting. >>> 11/30/04 in progress *065 Don Day, 11/02/04 -- Don will edit the msg00009 to incorporate the changes based on our discussion, and send out again as a new proposal (to be decided by ballot, or at next meeting with no discussion -- discussion to take place by email). >>> 11/30/04 done either way Will be done consistently with docbook ACTION: Nancy Harrison to send summary of DocBook table accessibility additions to TC list 066 Don Day, 11/09/04 -- Don has a list of bug fixes to submit. >>> Done 11/30/04 067 Michael Priestley, 11/09/04 -- Michael will give the "vocabulary" terminology explanation his best shot in the next draft of the spec, where it will be reviewed by everyone. >>> Done 11/30/04 ** Issues to be Resolved ** --------------------------- 005 All -- What should the scope and length of the conceptual introduction be? >>> We'll get this from JoAnn. >>> Still pending as of 11/9/04. >>> 11/30/04: to discuss in issues list for spec 006 All -- Should DITA specialization mechanism be documented in a separate specification in order to make it easier to use in other XML applications that otherwise have no relationship to topic-based writing? >>> Ongoing. >>> 11/30/04: - add to spec issues list 008 Namespace Subcommittee -- Decide namespace issues. New as of 8/31/04. >>> Resolved as of 11/9/04. 009 "Best Practices" document -- Let's put this on the agenda for future discussion. 010 Relationship between DITA and other topic-based architectures (such as S1000D) -- Need to incorporate this into the "Best Practices" document. 011 All -- Revisit use of @scale on image (general treatment of graphics, ie raster vs vector assumptions, etc.). Compare/contrast with controls for the <object> element, which in HTML subsumes the <img> element. >>> 11/30/04: see Actions 51, 55 above. <END> Regards, -- Don Day <> Chair, OASIS DITA Technical Committee IBM Lead DITA Architect 11501 Burnet Rd., MS 9037D018, Austin TX 78758 Ph. 512-838-8550 (T/L 678-8550) "Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?" --T.S. Eliot
← Prev in month
← Prev in thread
Next in thread →
Next in month →