dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] DITAbase for conversion
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "JoAnn Hackos" <joann.hackos@comtech-serv.com>
- Date: Thu, 24 Sep 2009 12:50:13 -0400
Hi JoAnn,
You wrote:
However, it seems that the
DTD developers took the TC’s approval of general task as the occasion
to completely rewrite the strict task using the constraint mechanism. I
don’t believe we ever voted to approve that. We could have more easily
created two independent task specializations. People would than have better
understood the conref requirements. Yes, we know that we cannot conref
between concept, task, and reference.
The approval happened two years ago
now, so it's understandable that memories are a bit fuzzy. But the proposal
is documented here, along with the approval date, and it explicitly talks
about using constraints.
http://wiki.oasis-open.org/dita/ImplementationStatus1.2
So if this is a surprise now, it's because
it took us two years to get to a review stage. We can go through
the whole discussion again, and obviously we need to, but I wanted to correct
the perception that this was somehow snuck in past the TC's wishes. We
did have a full discussion two years ago, and we did hash out all these
issues. I think we need to start by reviewing the records from two years
ago before we treat this as if it were a completely new issue.
As a side note, I believe Erik is incorrect
with regards to conref between e.g. task and concept. Conref between
document types with different domains or constraints is more problematic
than conref between document types with different high-level structures.
This is more similar to issues with
conref across documents with different domains. I believe we did have a
fairly deep discussion of conref implications at the time of the proposal
review, if we can find any records in the email archives.
Michael Priestley, Senior Technical
Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
From:
| "JoAnn Hackos" <joann.hackos@comtech-serv.com>
|
To:
| "Alan Houser" <arh@groupwellesley.com>,
"DITA TC" <dita@lists.oasis-open.org>
|
Cc:
| "Grosso, Paul" <pgrosso@ptc.com>
|
Date:
| 09/24/2009 12:21 PM
|
Subject:
| RE: [dita] DITAbase for conversion |
Alan is correct that we were
not assuming that the general task was intended only for specializations
when we originally approved the 1.2 proposal.
When I began work on the Adoption
TC’s feature description of general task, I worked directly with Alan’s
original proposal. I assumed, as you say, that this was a new task model
to accommodate different requirements for writing procedures. In fact,
I thought most of the changes were well considered.
However, it seems that the
DTD developers took the TC’s approval of general task as the occasion
to completely rewrite the strict task using the constraint mechanism. I
don’t believe we ever voted to approve that. We could have more easily
created two independent task specializations. People would than have better
understood the conref requirements. Yes, we know that we cannot conref
between concept, task, and reference.
Obviously, we can write about
it, but even the Adoption TC can’t work magic. I’m sure most new implementers
of DITA don’t know that our documents even exist, or know dita.xml.org
exists or how to find anything there.
JoAnn
JoAnn Hackos PhD
President
Comtech Services, Inc.
joann.hackos@comtech-serv.com
Skype joannhackos
From: Alan Houser [mailto:arh@groupwellesley.com]
Sent: Thursday, September 24, 2009 8:01 AM
To: DITA TC
Cc: Grosso, Paul
Subject: Re: [dita] DITAbase for conversion
There is a lot going on in this
thread, and I haven't been able to fully digest everything.
I will disagree that a motivation for the general task was as a basis for
specialization. The motivation was to provide an "out-of-the-box"
specialization that would be appropriate for a larger number of use cases
than would the 1.0/1.1 task model. The current (1.0/1.1) task model imposes
constraints that are either too restrictive or semantically irrelevant
(e.g., the required <cmd>) for many organizations.
So .... the motivation was to make DITA a better "fit", without
specialization, for a larger number of organizations and use cases.
Given this motivation, I would like to see ditabase include the general
task model. Other technical and delivery issues may take precedence, however.
-Alan
----
Alan Houser, President
Group Wellesley, Inc.
412-363-3481
www.groupwellesley.com
Grosso, Paul wrote:
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]