Groups - DITA TC minutes, 29 September 2009 (DITA_TC_meeting_29_September_2009.txt) uploaded

[keberlein@pobox.com]

-------------------------------------------------------
      OASIS DITA Technical Committee Minutes
                Tuesday, 29 September 2009
-------------------------------------------------------

Minutes recorded by Kristen James Eberlein.


1. ROLL CALL
Present: Robert Anderson, Rob Frankland, Paul Grosso, Kris Eberlein, Don
Day, JoAnn Hackos, Dick Hamilton, Elliot Kimber, Bruce Nevin, Jeff Ogden,
Dana 

Spradley, Su-Laine Yeo, Michael Priestley, Eric Sirois, Rob Hanna, Chris
Kravogel

Quorum is present.


2. APPROVE MINUTES FROM PREVIOUS MEETING
* 
http://www.oasis-open.org/committees/download.php/34353/DitaTcMeeting-2009-09-22.txt
Motion made to approve minutes; seconded by Kris Eberlein; motion carried by
acclamation.


3.ITEM: Conref constraints--do we have a problem? (was "Problems with the
task model")
* http://lists.oasis-open.org/archives/dita/200909/msg00080.html (JoAnn,
start of the thread)
* http://lists.oasis-open.org/archives/dita/200909/msg00325.html
(Priestley's proposal)
* http://wiki.oasis-open.org/dita/ConstraintsFaq (Anderson)

JoAnn Hackos proposed that task model be a specialization (rather than a
constraint) for DITA 1.2. 

Don Day asked "What would be the effect of this change?" Michael Priestley
answered that if we went with two peer task specializations, both
specialized 

from <topic>, we would need to rename all of the elements for the general
task model-- for example, <genericStep>, <genericCmd>, etc. (Because the
two 

tasks would not have a relationship, they could not inherit elements from
each other.)

Jeff Ogden (?) asked what problems would this proposal solve? It would mean
that educators would only need to explain specializations, not
constraints.

JoAnn stated that it would leave constraints as something that individuals
-- rather than the standard -- implemented.

Gershon Joseph expressed a concern that duplicating all the elements would
introduce confusion and make teaching DITA equally confusing; also, he
stated 

that he thinks it is good when a standard uses the technology that it
defines; the task model implemented with constraints is a good example of
how to 

use constraints. He stated that he did not see an advantage in having two
task specializations.

Bruce Nevin (?) asked if we did have two task specializations, wouldn't we
make the strict task a specialization of general tsak in order to maintain


ancestry? Elliot Kimber commented that we'd have to do this, otherwise
conrefing between the two task types would not be possible.

Don reiterated Jeff's question: "What problem are we trying to solve?"
JoAnn stated that the ability to conref content between the two task
information 

types is critical; she also emphasized that her proposal was meant to open
discussion about how best to handle the problem.

Robert Anderson stated that the problem will not be common; it would affect
people who use the same module (for example, task) in an organization with


different constraints AND they need to conref at the element level between
the two modules that implement different constraints.

Rob Hanna stated that he thought the current discussion was not hitting the
central issue: the intraoperability of different constrained information 

types without an implementation such as Michael has proposed.

Elliot Kimber rejoined the call, and stated that the reason we have
constraints is to solve the backward-compatibility problem that we
introduced with 

having a general task information model.

Jeff Ogden stated that if we went with the proposal to have two task
specialization from topic, we'd have even more restrictions about
conreffing between 

the two task information types. Michael Priestley answered yes, but that
would not be the problem if we went with the strategy of having strict task
be 

specialized from general task. (But we would be stuck with needing to come
up with some new element names ...) The third option is to implement his 

recent proposal. Michael also stated that if we went ahead with constraints
as currently implemented, he didn't think that many people would encounter


the reuse scenario that sparked this discussion.

JoAnn reiterated that she thinks a critical goal is to keep conrefs simple
and workable; her concern with the proposal for weak constraints is that it


might make it even more confusing for end users. She doesn't want DITA 1.2
to introduce levels of unpredictablility to organization's reuse
strategies; 

it will have a negative affect on DITA adoption.

Jeff Ogden stated that we've actually had this level of complexity already
with DITA 1.0 and 1.1. If people created their own customized doctype
shells 

that used different combinations of domain specializations, you'd have this
problem of more complex situations of when and where conrefs would work.

Elliot stated that he's always avoided this problem by always using the
same domains for every topic type used with an enterprise. The problem that
we 

are concerned about would only emerge if an information architect built
local shells or specialization with inconsistent sets of domains or
constraints 

-- or if you have two partners that are interchanging content, who have
inconsistent sets of domains for the same topic type, AND are conreffing
from one 

company's information set to the other company's information set.

JoAnn stated that she thinks the problem will emerge with a company that
naively implements both task and general task because it is there in what
OASIS 

provides; she thinks that this is highly likely and not an edge case.
Michael asked how, if the TC goes with the weak constraints proposal, such
as 

company would be affected? JoAnn commented that while it would permit
conreffing, it might also permit other stuff not intended. [JoAnn left the
TC call 

to conduct a workshop.]

Rob Hanna (?) asked whether another possibility might be to distribute the
strict task only, provide the general task as some special download, and to


counsel people not to use both task models.

? stated that if we go with Michael's proposal AND counsel information
architects to use strong constrains with caution, we get the best of all
worlds. 

End users won't need to know anything about constraints.

Discussion of how editing tools would validate constraints, both if we go
with Michael's proposal or not.

Su-Laine Yeo stated that she thought we needed to ship both DTDs; the
choice of which to use should be the company's. And being able to
copy-and-paste 

between the two task types is important, which we wouldn't have if we
implement two specializations of task.

Elliot suggested that this might be an issue for the Adoption Committee to
address. Jeff Ogden said that maybe the spec should have a few paragraphs


stating that it is not wise for companies to implement both task models
carelessly.

General consensus that the TC does not want to implement two
specializations of task, per JoAnn's original proposal.

General consensus that the TC should distribute both tasks, with clear
warnings in the spec for information architects, and explanation of what
the 

results/consequences of using both tasks would be.

Jeff Ogden stated that both the spec and Adoption Committee needs to
address the problem. He'll post an e-mail summarizing.

Su-Laine stated that she thinks most people are not aware of how many
restrictions on conref exist in DITA 1.1, since most editors do not check
for them.

Jeff suggested that some future TC meetings be scheduled for longer than
one hour. Gershon and Chris Kravogel expressed a preference for starting
the 

meeting earlier rather than later.


Meeting adjourned.

 -- Kristen Eberlein

The document named DITA TC minutes,  29 September 2009
(DITA_TC_meeting_29_September_2009.txt) has been submitted by Kristen
Eberlein to the OASIS Darwin Information Typing Architecture (DITA) TC
document repository.

Document Description:


View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=34527

Download Document:  
http://www.oasis-open.org/committees/download.php/34527/DITA_TC_meeting_29_September_2009.txt


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration