OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita] DITAbase for conversion



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]