My understanding was that one of the main reasons for the general
(looser) task model was as a basis for specialization (since a specialization
cannot be more general that its base, so you have to start with a fairly
general one).
And, if it is used by a customer as a basis for specialization, then
what they will want to have in their version of ditabase--for all the reasons
we want the stricter task in the TC one--is going to be their (stricter than
general) specialization of general task.
So having a ditabase with general task will do such users no good.
I don't think we should provide such. It will more likely
than not just cause users more problems when they think they can use such a
ditabase with their specialized-from-general tasks.
paul
From: Su-Laine Yeo
[mailto:]
Sent: Wednesday, 2009 September 23 16:18
To: DITA TC
Subject: RE: [dita] DITAbase for conversion
If I understand things correctly, it is clear to me now that
ditabase.dtd must use the stricter task model. Otherwise conrefs that point
from tasks to <task> targets within a composite document will immediately
be considered invalid by any validation tool that uses DITA 1.2 DTDs. A lot of
conrefs created in DITA 1.0 and 1.1 would be considered invalid by DITA
1.2 processors if we loosen ditabase.dtd.
So the only question left is how the need for looser
versions of ditabase should be filled: By the DITA TC, by individual
implementers of DITA, or something in-between. I think the right answer depends
on how often a looser version would be needed. If the need is very common then
I think the TC should provide it. I don’t have data indicating that the
need is very common. Does anyone else?
Regards,
Su-Laine
Su-Laine Yeo
Interaction Design Specialist
JustSystems Canada, Inc.
Office: 778-327-6356
www.justsystems.com
From: Joann Hackos
[mailto:]
Sent: Wednesday, September 23, 2009 1:59 PM
To: Michael Priestley; ; Hal Trent; Frank Miller
Cc: DITA TC; Eliot Kimber; Kristen Eberlein
Subject: Re: [dita] DITAbase for conversion
HI All,
I concur with Michael’s statement. It don’t want to rely upon the
authors (inhouse, vendors, around the world) remembering what is not allowed.
The constraints are designed to keep the authoring consistent across a wide
variety of knowledge and experience. So I would not use any
“general” model where I wanted constraints. Of course, I might want
a different set of constraints that is currently available in the current
constrained task.
I think the arch spec needs to make this relationship very, very clear to
everyone. The backwards compatibility is a huge problem if people start using
“general” task without knowing its consequences. It’s
presence under the name “task” in an editor makes the possibility
of serious problems enormous for organizations.
I intend to discuss it in the technical content sections of the arch spec once
the 2nd review is complete. I hope its a major discussion under the constraint
mechanism. This needs to come with huge warnings.
JoAnn
On 9/23/09 9:28 AM, "Michael Priestley" <> wrote:
Hi Rob,
While it is true that the conrefs would work if an organization switched
wholesale from the current constrained task to a looser model, that's not
backwards compatibility - that's saying that if someone wants to preserve their
current reuse strategy they should throw out their content guidelines.
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
http://dita.xml.org/blog/25 <http://dita.xml.org/blog/25>
From:
"Rob
Hanna" <>
To:
"'ekimber'"
<>, "'Kristen
James Eberlein'" <>,
"'JoAnn Hackos'" <>
Cc:
"'dita'"
<>
Date:
09/23/2009
10:57 AM
Subject:
RE:
[dita] DITAbase for conversion
I understand the
compatibility problems between constrained and
unconstrained conrefs. It shouldn't present a problem in environments where
DITA 1.1 DTDs are upgraded to DITA 1.2 DTDs with the unconstrained task
model. It is not a backward compatibility issue. Technically, the older DITA
1.1 task topics will also be unconstrained but be written to resemble the
constrained task model.
Cheers,
Rob
