RE: [dita] How much flexibility do specializers have to make exceptions

During today’s DITA TC call we agreed:

1) To continue the discussion about “how much flexibility do specializers have” or “what is required and what is optional”.

2) But to put the general discussion of this issue on hold for now.

3) And proceed to deal with this in a more specific case by case fashion as the DITA 1.2 specification drafts are produced.

4) And to move forward on the other three items that were waiting on the list behind this issue.

The other three discussion items that have been waiting behind the “how much flexibility” item for some time are:

What does it mean when we say that an implementation supports the DITA standard? Is the entire standard required or are some parts optional?

· The specification editors will draft a conformance statement for the DITA 1.2 Architectural Specification. Eliot will help. The TC as a whole can comment on the draft and needs to approve all of the DITA 1.2 specs at some point. Alan’s recent note spoke to this issue as well. His note is included below.

Is the scope of DITA 1.2 as it is shaping up too large? Is the DITA specification becoming too complex?

The first question is probably something of a moot point now that we are almost done with the DITA 1.2 approval process. I think the TC needs to have a discussion of the schedule for the rest of the DITA 1.2 work. There is enough fairly complicated stuff in DITA 1.2 that it will take sometime to get this all documented and implemented in the OASIS DITA DTDs and schemas and possibly even longer to get vendor implementations including implementations in the DITA Open Toolkit, so that we can get the required two certified users for each component.
The second question is one that we should probably talk more about during a TC call. In the same note Alan raised some questions related to partial vendor implementations and “cherry-picking” that may be related to the size and complexity of the DITA releases. Alan’s note is included below.

Is the approach outlined in the proposed DITA 1.2 documentation TOC a good approach?

See: http://wiki.oasis-open.org/dita/Draft_1.2_TOC
The DITA 1.2 Specifications will be broken up into several collections based on families of specializations rather than having just the two all inclusive Architecture and Language Reference specs.
This is the approach that is being taken now for DITA 1.2.
Comments and suggestions on this approach are welcome anytime. Send comments to the DITA TC list or to Michael.
The DITA TC will formally review and approve the specification at some point, but I can imagine that the specification editors will be grumpy if suggestions for a very different organization are made that late after the work has already been done. So it would be best to get any general comments on this approach to organizing the DITA specifications in early.

Of course we can and probably should have much of the discussion of these items on the DITA TC list between TC calls. Who wants to go first?

And out of all of this I think there are at least two items for next week’s TC agenda:

1) Discussion of the schedule for the rest of the DITA 1.2 work.

2) Discussion of DITA size and complexity, partial implementations, and “cherry-picking”.

-Jeff

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]

Sent: Tuesday, January 15, 2008 10:38 AM

To: Alan Houser

Cc: dita@lists.oasis-open.org; Ogden, Jeff

Subject: RE: [dita] How much flexibility do specializers have to make exceptions to behaviors that are outlined in the DITA standard?

For what it's worth, I also think the issue of conformance is important. I agree with others on that point. I just disagree with the base functionality being uncustomizable, at least as a blanket statement. Customizations that respect the syntax of the markup (ie, they won't force unnatural usages in markup that would break other tools), use standard mechanisms like outputclass, etc. need to be explicitly allowed, and currently are.

So I support the call for required support for key processes such as conref, but don't support a blanket moratorium on customizations of those processes.

Michael Priestley

Lead IBM DITA Architect

mpriestl@ca.ibm.com

http://dita.xml.org/blog/25

> From: Ogden, Jeff [mailto:jogden@ptc.com]

> Sent: Tuesday, January 15, 2008 10:54 AM

> To: dita@lists.oasis-open.org

> Subject: RE: [dita] How much flexibility do specializers have to make

> exceptions to behaviors that are outlined in the DITA standard?

> Thanks Don. Sorry I missed the note from Deborah. [Deborah’s note is included below]

> And Alan Houser just posted a note to the TC list in which he said it

> was important.

> That makes 3 responses. None saying that the issue is unimportant.

> -Jeff

> > -----Original Message-----

> > From: Don Day [mailto:dond@us.ibm.com]

> > Sent: Tuesday, January 15, 2008 10:12 AM

> > To: Ogden, Jeff

> > Subject: RE: [dita] How much flexibility do specializers have to make

> > exceptions to behaviors that are outlined in the DITA standard?

> >

> > Deborah Pickett did weigh in, Jeff. Although it was not as strongly

> > asserted as Eliot's note, I read it as a "somewhat important" reply.

> >

> > Regards,

> > --

> > Don Day

> > Chair, OASIS DITA Technical Committee

> > Chair, IBM DITA Architects Board

> > Email: dond@us.ibm.com

> > 11501 Burnet Rd. MS9033E015, Austin TX 78758

> > Phone: +1 512-244-2868 (home office)

> -----Original Message-----

> From: Alan Houser [mailto:arh@groupwellesley.com]

> Sent: Tuesday, January 15, 2008 10:12 AM

> To: Ogden, Jeff; dita@lists.oasis-open.org

> Subject: RE: [dita] How much flexibility do specializers have to make

> exceptions to behaviors that are outlined in the DITA standard?

> Hi Jeff,

> I've been bandwidth-constrained recently, and my contributions to the

> DITA TC have suffered.

> I am quite concerned about the level of commercial tools support we've

> seen thus far for DITA 1.0 and 1.1 (does any commercial vendor fully

> support DITA 1.1? Perhaps only PTC?). I see vendors "cherry-picking"

> features for implementation, and ignoring others. I fear the situation

> will worsen with the number and complexity of the new DITA 1.2 features.

> I think the issue of assessments and requirements for DITA conformance

> is important for the continued viability of the standard.

> -Alan

> --

> Alan Houser, President

> Group Wellesley, Inc.

> 412-363-3481

> www.groupwellesley.com

> -----Original Message-----

> From: Ogden, Jeff [mailto:jogden@ptc.com]

> Sent: Tuesday, January 15, 2008 9:49 AM

> To: dita@lists.oasis-open.org

> Subject: RE: [dita] How much flexibility do specializers have to make

> exceptions to behaviors that are outlined in the DITA standard?

> I promised to send out a summary of the responses that were received on

> the question about what is or isn't required by the DITA Standard and if

> this issue is important enough to continue to spend time on it or not.

> There was only one response. It was from Eliot Kimber, is included

> below, and was sent to the entire TC list. Eliot is one of the three or

> four people who has been active in this discussion all along. He clearly

> thinks that this is important enough to continue to spend time on.

> Not sure what conclusions we can draw from a single response. One

> possible conclusion is that continuing the discussion wins by a score of

> one to nothing.

> -Jeff

From: Deborah_Pickett@moldflow.com [mailto:Deborah_Pickett@moldflow.com]
Sent: Wednesday, January 09, 2008 7:05 PM
To: Ogden, Jeff
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] How much flexibility do specializers have to make exceptions to behaviors that are outlined in the DITA standard?

I care enough that implementations that want to add extended functionality are not actively prevented from doing so. Hence my remarks about un-enumerating @collection-type.

I don't mind if such implementations are labelled with a lesser conformance status. I don't mind if the DITA standard insists that such implementations use prefixes like "x-" a la other standards.

--
Deborah Pickett
Information Architect, Moldflow Pty Ltd, Melbourne
Deborah_Pickett@moldflow.com

> > -----Original Message-----

> > From: Eliot Kimber [mailto:ekimber@reallysi.com]

> > Sent: Wednesday, January 09, 2008 7:01 PM

> > To: dita@lists.oasis-open.org

> > Cc: Ogden, Jeff

> > Subject: Re: [dita] How much flexibility do specializers have to make

> > exceptions to behaviors that are outlined in the DITA standard?

> >

> > Ogden, Jeff wrote:

> > > This is a note that Don Day asked me to send out during yesterday's

> > > DITA TC call.

> > >

> > > About a week ago I restarted the discussion about what the DITA Standard

> > > REQUIRES, strongly RECOMMENDS, and what is OPTIONAL. So far the

> > > restarted discussion has been between just me, Michael, and Eliot.

> > > What I'd like to find out from others on the TC is if these issues are

> > > important enough to continue to spend time on them or not?

> > >

> > > So please let me know by sending a short reply either to me or to the

> > > DITA TC list. I'll summarize the responses before next Tuesday's

> > > DITA TC call.

> >

> > I think this is very important.

> >

> > The DITA specification needs a conformance statement, which it

> > currently does not have.

> >

> > Without a conformance statement we don't really have a standard

> > because there's no formal basis on which to judge any given use or

> > implementation of DITA for correctness against the dictates of the

> > specification, in particular, in terms of what things are optional and

> > what are required. The closest there is are some statements in the

> > architecture spec about requirements for specializations, but nothing

> > that relates to processors.

> >

> > In order to make a conformance statement the spec must be clear about

> > what is invariant and what is suggested. It currently does not do that

> > with sufficient clarity (obviously, or we wouldn't be having this

> > discussion).

> >

> > There is also the question of whether there should be different levels

> > of conformance based on support for different set of optional features

> > or if all features of DITA are required. For example, we have to decide

> > if a processor that does not implement support for non-standard

> > specializations is or is not conforming. Of course, the easy answer

> > (and probably the correct answer for DITA 1.1) is that there are no

> > optional features.

> >

> > And of course this all ties into the fuzzier question of what it means

> > to "support DITA" in certain types of tools and whether or not that's

> > something specification should address normatively or informatively or

> > remain silent on. For example, it might make sense for the TC to issue

> > a separate technical report on support for DITA in content management

> > systems that offers guidance by defining some testable categories of

> > support without trying to define formal conformance levels or anything.

> >

> > Cheers,

> >

> > Eliot

> > --

> > Eliot Kimber

> > Senior Solutions Architect

> > "Bringing Strategy, Content, and Technology Together"

> > Main: 610.631.6770

> > www.reallysi.com

> > www.rsuitecms.com

dita message