[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: DITA Technical Committee Meeting Minutes: 23 January 2007
-- Gershon L Joseph Director of Technology and Single Sourcing Tech-Tav Documentation Ltd. Secretary, OASIS DITA Technical Committee Secretary, OASIS DITA Translation Subcommittee Member, OASIS DocBook Technical Committee office: +972-8-974-1569 mobile: +972-57-314-1170 web: http://www.tech-tav.com
DITA Technical Committee Meeting Minutes: 23 January 2007
(Recorded by Gershon Joseph <gershon@tech-tav.com>)
The DITA Technical Committee met on Tuesday, 23 January 2007 at 08:00am PT
for 60 minutes.
1. Roll call
We have quorum.
2. Approve minutes from previous business meeting:
http://lists.oasis-open.org/archives/dita/200701/msg00058.html (16 Jan 2007)
Accepted (Don moved, Gershon seconded, no objections)
3. Business:
3.1 ITEM: Ongoing review of 1.1 drafts
* Architectural Spec: http://lists.oasis-open.org/archives/dita/200701/msg00039.html
No general comments beyond what was sent to list.
* Language Spec: http://lists.oasis-open.org/archives/dita/200701/msg00048.html
Don suggested generating an alphabetical list of elements.
Robert is working on it.
Don: Deborah Pickett found that figgroup content model is limiting.
How do we want to respond?
The TC discussed and this issue will be added to the 1.2 list, since we're
so far ahead on 1.1 already.
ACTION: Michael to respond to Deborah explaining the TC decision.
* Fix List: http://wiki.oasis-open.org/dita/Fix_list_for_1.1_Language_Spec_draft
* DTD: http://lists.oasis-open.org/archives/dita/200701/msg00049.html
* XSD: http://lists.oasis-open.org/archives/dita/200701/msg00070.html (new)
2. Paul Grosso's discussion issues:
* Arch Spec comments http://lists.oasis-open.org/archives/dita/200701/msg00079.html
* chunking
Paul: One of our big concerns is default listed as trying to match
input file structure with output file structure. While the toolkit
does it this way, it's a bad idea because the author needs to know
about the chunking. Chunking should rather be based on various
kinds of context and parameters where implementation knows how to
do it the right way for each output. We don't want to see the
default doing that, the default should rather do the "right thing"
which is the best thing for the user.
Michael: Depends on writer background. For me, it was natural to
think of it as the same chunking, since I'm used to writing HTML.
I understand where you're coming from and I've worked with systems
that make the chunking for me, though such systems never did the
chunking I expected.
Paul: Most committee members are not your average user. Most users
want to pull stuff out of a CMS and have the system chunk it.
Paul: I'm just saying I don't think the current behavior should be
the default. It can be one of the possible behaviors though.
Michael: We could put an attribute on the map that determines
chunking behavior. We don't want to force toolkit users to have to
now add @chunk="file" to get the current toolkit behavior, since
that would be backwards incompatible. I'd like to say both
approaches are valid, use a base setting on the map.
Paul: As long as the default is implementation specific.
Michael: I'd like to say the default is implementation specific and
process specific, and the default can also be set on the map. I
don't want users to have to manually add the chunk attribute.
Discussion on whether we should address the chunk attribute in 1.1
or push it off...
Michael: Let's give one more week on the chunk attribute on the list
and dedicated conf calls.
Don: Reissue the spec after we get input from the @chunk task force.
Michael offered to take the task force and will arrange a meeting this week.
* ditaval
Paul: I think the TC already discussed ditaval. Even though Jeff has concerns,
the TC process made a decision and can ignore the ditaval comments.
DECISION: Michael moved to add an acknowledgement to Jeff Ogden and Robert Anderson
for their efforts and contribution to the 1.1 spec. JoAnn seconded. No objections.
3. Eliot Kimber's discussion items:
* attribute specialization:
* http://lists.oasis-open.org/archives/dita/200701/msg00075.html and following
Eliot: it's not clear on how to specialize from base.
Michael: It is documented. Need to create one attribute per domain.
The syntax is documented.
Eliot: I'll look at it again.
Discussion on specializing and generalizing attributes...
* topic nesting and ditabase:
* http://lists.oasis-open.org/archives/dita/200701/msg00084.html
* http://lists.oasis-open.org/archives/dita/200701/msg00085.html
Eliot: In some contexts the spec says you can't nest, while in
other contexts the spec says one can nest. Why do we need two
different rules for topic nesting?
Michael: To support the need for hybrid documents. Ditabase handles that.
Pure info type documents should not allow other info types -- that's
why they don't. The spec is illustrating that there are two approaches.
Eliot: The normative spec should not ship with both approaches.
Don requested to move this discussion to the list.
--out of time--
* glossaries and glossary linking:
* http://lists.oasis-open.org/archives/dita/200701/msg00083.html
* http://lists.oasis-open.org/archives/dita/200701/msg00086.html
4. ITEM: Review schedule for CD vote (initiate the 1.1 review process)
* action to revisit
5. ITEM: SC updates
4. Announcements/Opens
-- Meeting adjourned at 09:00 --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]