[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: MEETING MINUTES -- 07 February 2006 -- DITA TECHNICAL COMMITTEE
MEETING MINUTES -- 07 February 2006 -- DITA TECHNICAL COMMITTEE
(Minutes taken by Seraphim Larsen <seraphim.l.larsen@intel.com>)
Date: Tuesday, 07 February 2006
Time: 08:00am - 09:00am PT
DITA Technical Committee website:
- Public: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita
- Members only: http://www.oasis-open.org/apps/org/workgroup/dita/
- Wiki: http://wiki.oasis-open.org/dita/
- Roll call
- We have quorum
- ACTION for Don and Seraphim to review membership guidelines,
and clean up the membership list to make sure we can get
quorum
- Review/approve minutes from previous meeting:
- http://lists.oasis-open.org/archives/dita/200601/msg00037.html (31 Jan 2006)
- Don Day proposes to approve the minutes as read, Alan
Houser seconds, no objections, approved by acclamation.
- News, events:
- Translation liaison meeting report
- JoAnn Hackos provided a summary --
- There is considerable interest
- to define best practices for authoring for
translation
- to ensure that the various standards work together
effectively
- Many people attended, from the localization service
provider industry and people who participate on other
standards committees
- There was some discussion on inline elements, some of
the potential issues around author control of the
translate yes/no attribute
- Most of this will be covered by "best practices"
- There was optimism that they could produce a transform
to go between XList and DITA pretty quickly
- Don -- If we can get the right players together, we can
make this an Open Source project
- JoAnn -- Thanks Robert Anderson and Chris Wong for their
help with this!
- Chris provided some details of the discussion
- Resource: OASIS DITA Wiki http://wiki.oasis-open.org/dita/FrontPage
- Our previous work on items accepted for DITA 1.1 is here:
- http://wiki.oasis-open.org/dita/AcceptedAndCandidate
- Resume review of "left off the list" and unnumbered proposals for
1.1 scope (http://wiki.oasis-open.org/dita/OffTheList#preview)
- "Recognizing DITA Documents"
- SUMMARY: Paul Prescod moves that the 1.1 specification
should say that tools should support both .dita and .xml,
but it is recommended as a best practice that .dita be
used.
- Michael Priestley -- Seconds
- No objections -- Approved by acclamation.
- DISCUSSION:
- Paul Prescod (PP) -- One issue -- You can't recognize
DITA documents in general until after you've
identified the document type. So, they're system
first identifies the document type, and then decides
whether it's DITA or not. The biggest gap is actually
in the DITA toolkit -- you need to be consistent
within maps with the file extensions that you use.
- Don Day (DD) -- The use of .dita is really a best
practice rather than a convention (as opposed to
using .xml). Is this an item that needs to be put
on the list for integration into the
specification? (That the recommended best
practice of using file extensions to identify file
types, be rolled into the specification.) Because
it's not in the specification, tool vendors are
having trouble with it.
- PP -- Tools should support both standards. The
spec should recommend .dita, we should be pushing
people that way. It is certainly a toolkit issue,
but should also be addressed by the spec. The
user community should prefer .dita.
- DD -- It's not apparent when you are looking at
a list of XML files, it's not clear from the .xml
extension which ones belong to DITA.
- PP -- Tools should support both extensions, but
.dita is preferred for usability reasons.
- MP -- We all agree that both .dita and .xml should
be supported in the tools.
- Paul Prescod proposes that the 1.1 specification
should say that tools should support both .dita
and .xml, but it is recommended as a best practice
that .dita be used.
- Michael Priestley -- Seconds
- No objections -- Approved by acclamation.
- Start of documenting DITA design principles (Paul Prescod)
- http://lists.oasis-open.org/archives/dita/200510/msg00005.html
- SUMMARY: It is decided to move the discussion to the Wiki
-- this is not an issue for 1.1.
- DISCUSSION:
- MP proposes that PP and MP should collaborate on a new
list (or updated list), and bring that back to the TC
as a proposal.
- MP -- It doesn't affect DITA or any current
implementations.
- Don -- The Wiki is the best place for this kind of
documentation to start and to proceed. It's
a good place to collaborate.
- Recommend moving the discussion to the Wiki --
this is not an issue for 1.1.
- Module Registry proposal (Bruce Esrig)
- http://lists.oasis-open.org/archives/dita/200510/msg00097.html
- SUMMARY: Don Day moves to close this item as a 1.1
specification item, and initiate an action item to put
this on a future agenda.
- Bruce Esrig seconds
- No objections, approved by acclamation.
- DISCUSSION:
- Bruce -- The question is whether this is a DITA spec
issue at all. Should something be done to make sure
the DITA namespace doesn't get cluttered with new
specializations, especially since people will be
addressing similar problems in different way? That's
the idea behind the module registry.
- MP -- Having something more formal (a URL where
you are guaranteed to find a particular module)
allows you to build a DITA DTD to match
specialized content that you may come across, just
by refering to the Module Registry. This could
even be automated.
- Don -- Could this be an Open Source or commercial
tool that can handle this?
- MP -- Yes, a tool could do that, but the
repository itself would need to be on OASIS.
- Don -- With all the issues already on our plate
for 1.1, and limited resources for completing the
1.1, should we postpone this till after 1.1 is
completed?
- MP -- There might be work for the TC to do,
but most of the work would fall on OASIS.
- The proposal is that we ask the OASIS
administration to set this up for us.
- PP -- It will still take a lot of our time
to tell them what the requirements are and
how it should be set up.
- JoAnn -- Shouldn't we put this on Bruce's
area on dita.xml.org?
- Don -- That would meet about 80% of the
value. Is it worth the additional 20% to
get the OASIS people to make this happen?
- Erik Hennum -- Would this work like the
Perl CPAN model?
- MP -- That depends on where you keep the
.mod files
- Erik -- You'd prefer to pull plugins from
multiple sites.
- MP -- For base DITA, you've got the design
modules at OASIS, and the open-source
processing for it is all at sourceforge.
We'd want to continue that distinction for
specialization -- sourceforge for
processing, but the modules themselves at
OASIS?
- Don -- This could take a lot more
discussion -- to close on it for now,
we're trying to figure out what is in the
1.1 specification space for now. Since
this isn't in the 1.1 specification
space, can we discuss it somewhere else?
Let's make this a future TC agenda item.
- Don Day moves to close this item as a 1.1
specification item, and initiate an action
item to put this on a future agenda.
- Bruce Esrig seconds
- No objections, approved by
acclamation.
- Clarification of Chunk attribute (Erik Hennum)
- http://lists.oasis-open.org/archives/dita/200511/msg00070.html
- PROPOSAL -- Don Day moves to include this item within the
1.1 scope.
- Paul Grosso seconds
- No objections, approved by acclamation
- Criteria for making distinction between general and
industry-specific DTDs/schemas (future agenda discussion)
- Don -- Is this in the scope of 1.1, or is this an
implementation issue? It doesn't seem like
a specification-level issue.
- No objections, so we'll drop this as a 1.1 issue and keep
it for a future agenda.
- Graphic (image) scaling improvements (Paul Grosso)
- http://lists.oasis-open.org/archives/dita/200601/msg00025.html
(and following responses)
- SUMMARY: Don proposes to accept Paul's recommendation as
a 1.1 design issue.
- Bruce Esrig seconds.
- No objections, approved by acclamation
- DISCUSSION:
- Paul Grosso summarized the proposal. We need to be
able to scale images. He has two specific
recommendations, which are both backwards-compatible.
- Recommendation #1: Add the "scale" attribute to
the "image" element, and change the declared type
of the scale attribute to NMTOKEN. Define the
allowable value space of the scale attribute to be
any unsigned integer.
- Recommendation #2: Augment the DITA spec to say
that the value space of the height and width
attributes on the image element is a length which
is a real number with an optional unit. The
allowable units are pc, pt, px, in, cm, mm, em (an
omitted unit implies px). This requires no change
to the DTDs/Schemas.
- Don -- Is this 1.1 scope?
- The proposal is to introduce scale as an image
attribute, and to broaden the range of values
you can use for height, width, and scale.
- Table uses "scale" for font scaling. Graphics
would need to use "scale" for image size
scaling.
- Several people chimed in, that yes, this is an
issue for their users.
- Bruce Esrig, for example, sees a need for
this issue to be addressed.
- Don proposes to accept Paul's recommendation as
a 1.1 design issue.
- Bruce Esrig seconds.
- No objections, approved by acclamation
- Michael Priestly raised a new point whether we should add
a namespace for DITA to the 1.1 spec --
- ACTION for Michael to start discussion on the list.
- ACTION for Don to include this on a future agenda.
<end>
___________________________________________________________
Seraphim Larsen CIG Operations / TPPE
Senior Technical Writer Intel Corporation
(480) 552-6504 Chandler, AZ
The content of this message is my personal opinion only.
Although I am an employee of Intel, the statements I make
here in no way represent Intel's position on the issue, nor
am I authorized to speak on behalf of Intel on this matter.
___________________________________________________________
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]