[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 <dond@us.ibm.com>
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]