Hopefully this is less garbled.
|------------------------+------------------------+------------------------|
|Option
|Who benefits?
|Who's hurt, and when? |
|------------------------+------------------------+------------------------|
|1. Do
nothing. |1) No new DTD /
Schema |1) People
with |
|
| updates required |customized shells
that |
|
|
|do not want the loose |
|
|2) People who want the |task model, and who have|
|
| loose model
|not read the spec to |
|
| automatically |find out
about the |
|
|
|change. Affected as soon|
|
|
|as they move to 1.2. If |
|
|
|they notice quickly, |
|
|
|they can learn how to |
|
|
|add the constraint and |
|
|
|add it; if they notice |
|
|
|late, they may already |
|
|
|have docs that make it |
|
|
|tough to add the |
|
|
|constraint.
|
|------------------------+------------------------+------------------------|
|2. Rename the existing
|1) People with custom |1) People who do not use|
|task.mod to
be |shells who want
the |catalogs for their local|
|generalTask.mod, create
|strict model. I am |doctypes - but they're
|
|new PUBLIC IDs and URIs
|assuming the deprecated |already in trouble due |
|that point to the
“new” |task.mod gives the |to our new
directories, |
|file, change all of the
|strict model in one way |so they'll just be a bit|
|DITA 1.2 files that we
|or
another.
| more confused that task|
|distribute to use
the
|
| is now "deprecated" |
|new PUBLIC IDs or URIs,
|
|
|
|rename the task doctype
|
|2) People who rely on |
|shells to strictTask.dtd|
|catalogs for the DTD |
|or .xsd, keep
the
|
|only, but system IDs for|
|existing PUBLIC ID and
|
|the modules, are also |
|URIs for the
task
|
| forced to change |
|doctype shells pointing
|
|
|
|to strictTask,
create
|
|
|
|new “strictTask”
PUBLIC
|
|
|
|IDs and URIs that also
|
|
|
|point to the strictTask
|
|
|
|doctype shells, create
|
|
|
|deprecated/dtd/task.mod
|
|
|
|and
|
|
|
|deprecated/xsd/taskMod.x|
|
|
|sd and point
the
|
|
|
|existing PUBLIC IDs and
|
|
|
|URIs at
it.
|
|
|
|------------------------+------------------------+------------------------|
From: Bruce Nevin
(bnevin) [mailto:]
Sent: Tuesday, November 10, 2009 10:37 AM
To: Ogden, Jeff; dita
Subject: RE: [dita] strict task vs. general task vs. the file naming and
module rules
This seems to have got garbled:
2) People who rely on
catalogs for the DTD
doctypes - but they're
only, but system IDs for
the modules, are also
forced to change
more confused that task
is now "deprecated"
Could you sort it out, please?
From: Ogden, Jeff [mailto:]
Sent: Tuesday, November 10, 2009 9:28 AM
To: dita
Subject: [dita] strict task vs. general task vs. the file naming and
module rules
Back to our continuing saga of strict task vs. general
task vs. the file naming and module rules and compatability between DITA 1.0,
1.1, and 1.2 task customizations.
I've been trying to think of ways to make progress on
this issue.
My collusion is that we are trying too hard to reach a
consensus and in trying to do that we've put more and more compromises on the
table, each one more complicated, more confusing, and less satisfactory. I
think we should stop doing that, put the fundamental alternatives on the table
for the TC to discuss once more and then have the TC vote to choose one of the
alternatives.
My suggestion is that the TC choose between these two
alternatives:
1. Status
quo. Users with customized DITA 1.0 or 1.1 task document type shells will
implicitly switch from the strict to the general task model when they move to
DITA 1.2 unless they take steps to add the new strict task constraint to their
existing specializations. We continue to follow all of the design pattern rules
for file naming and module separation. This is option #1 in the summary table
below.
2. Make
changes so that existing DITA 1.0 and 1.1 task customizations remain
compatible in DITA 1.2. Add new files and make changes to existing files,
PUBLIC IDs, and URIs so that existing DITA 1.0 and 1.1 task document type
shells continue to use the strict rather than the general task model. This will
violate the existing design pattern file naming and module separation rules. In
the DITA 1.2 spec. make the file naming rule a SHOULD rather than a MUST. Place
the files (task.mod and taskMod.xsd) that violate the module separation rules
in a deprecated directory where they will not be used by any other DITA 1.2. We
will keep the deprecated directory and non-conforming files until we get to
DITA 2.0 where we can make incompatible changes.
Either approach will require updates to the DITA 1.2
spec. to explain to people what is going on and what they need to do to get
various behaviors that they may want.
No matter which option the TC chooses we should add new
PUBLIC IDs and URIs that include the phrases “strict task” and
“general task” rather than simply “task” so that it is
clearer what type of task model one is getting when using the various doctype
shells and modules. We would maintain the existing unqualified
“task” PUBLIC IDs and URIs to maintain compatibility with prior
releases.
Not included is a third alternative that the TC has
previously decided not to pursue:
3. Abandon
constraints as the method to create general and strict tasks in favor of a
new specialization and new doctype shells that avoid the problems associated
with reusing the existing task.mod and taskMod.xsd files and identifiers for
new purposes.
If someone on the TC feels strongly that this alternative
should be considered, they should say so.
As I’m sure everyone knows by now, I prefer option
#2. I don’t like option #1, but I do think it is better than
alternative #3.
Here is a summary that was put together during some
private e-mail exchanges between Michael, Robert, and me and then updated by me
to reflect the details of the current proposals.
|------------------------+------------------------+------------------------|
|Option
|Who benefits?
|Who's hurt, and when? |
|------------------------+------------------------+------------------------|
|1. Do
nothing. |1) No new DTD /
Schema |1) People
with |
|
| updates required |customized shells
that |
|
|
|do not want the loose |
|
|2) People who want the |task model, and who have|
|
| loose model
|not read the spec to |
|
| automatically |find out
about the |
|
|
|change. Affected as soon|
|
|
|as they move to 1.2. If |
|
|
|they notice quickly, |
|
|
|they can learn how to |
|
|
|add the constraint and |
|
|
|add it; if they notice |
|
|
|late, they may already |
|
|
|have docs that make it |
|
|
|tough to add the |
|
|
|constraint.
|
|------------------------+------------------------+------------------------|
|2. Rename the existing
|1) People with custom |1) People who do not use|
|task.mod to
be |shells who want
the |catalogs for their local|
|generalTask.mod, create
|strict model. I am |doctypes - but they're
|
|new PUBLIC IDs and URIs
|assuming the deprecated |already in trouble due |
|that point to the
“new” |task.mod gives the |to our new
directories, |
|file, change all of the
|strict model in one way |so they'll just be a bit|
|DITA 1.2 files that we
|or
another.
| more confused that task|
|distribute to use
the
|
| is now "deprecated" |
|new PUBLIC IDs or URIs,
|
|
|
|rename the task doctype
|
|2) People who rely on |
|shells to
strictTask.dtd|
|catalogs for the DTD |
|or .xsd, keep
the
|
|doctypes - but they're |
|existing PUBLIC ID and
|
|only, but system IDs for|
|URIs for the
task
|
|the modules, are also |
|doctype shells pointing
|
|forced to change |
|to strictTask,
create
|
|more confused that task |
|new “strictTask”
PUBLIC
|
|is now "deprecated" |
|IDs and URIs that also
|
|2) People who rely on |
|point to the strictTask
|
|catalogs for the DTD |
|doctype shells, create
|
|only, but system IDs for|
|deprecated/dtd/task.mod
|
|the modules, are also |
|and
|
|forced to change |
|deprecated/xsd/taskMod.x|
|
|
|sd and point
the
|
|
|
|existing PUBLIC IDs and
|
|
|
|URIs at
it.
|
|
|
-Jeff
