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

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:] 

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

To: Alan Houser

Cc: ; 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 



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

 

 

> From: Ogden, Jeff [mailto:]

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

> To: 

> 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:]

> > 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: 

> > 11501 Burnet Rd. MS9033E015, Austin TX 78758

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

 

 

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

> From: Alan Houser [mailto:]

> 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?

> 

> 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:]

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

> To: 

> 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:
 [mailto:] 

Sent: Wednesday, January 09, 2008
7:05 PM

To: Ogden, Jeff

Cc: 

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

 

 

 

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

> > From: Eliot Kimber [mailto:]

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

> > To: 

> > 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