[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Groups - DITA TC minutes, 29 September 2009 (DITA_TC_meeting_29_September_2009.txt) uploaded
------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]