← Prev in month ← Prev in thread
Next in thread → Next in month →

MEETING MINUTES -- 30 NOV 2004 -- DITA TECHNICAL COMMITTEE

From
Eon Eay
Date
2004-12-07T15:39:07+00:00
ID
Thread
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 →