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

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


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