RE: [dita] Re: Strawman Draft of General Conformance Specification

[Deborah_Pickett@moldflow.com]

"Ogden, Jeff" <jogden@ptc.com> wrote
on 06/03/2008 03:31:26 AM:
> > I think the statement about specialization-awareness needs to
be 
> > strengthened.  If a DITA editor ("topic-conformant")
has extra 
> > features that it can apply to tasks, then I want to be confident
> > that those extra features are inheritable by my own specializations
> > of task.  I don't know how best to word this, but it's essentially
> > about holding implementations to the spirit of specialization,
and 
> > not just catering to their Chosen Few doctype shells.  Commercial
> > DITA editors are, in my experience, often guilty of this. 

> Again I don’t know how or even if we should
require something like 
> this in the face of all possible “extra” features. I think we can
> encourage more full disclosure, so that people know what they are
> and aren’t getting.

I wonder if this would fall out automatically if we
defined specialization conformance in terms of modules rather than shells.
 It would stop dodgy implementations from detecting magical doctype
public IDs (-//OASIS//DTD DITA Task//EN turning on features) and allow
users to get the features even in their cut-down, without-useless-domain,
shells.

If we just hand out six or seven shells for reference,
and insist that DITA implementations support those shells as a minimum,
then implementations will surface which support only those six or seven
shells, and still claim to be conforming implementations.  I think
it's within the TC's power to give that a lesser class of conformance (IMO
not at all, but that might be considered harsh.)

Note that I'm not advocating that implementations
have implement such features a certain way.  I'm contributing to what
is, in my view, the minimum that I'll tolerate in a DITA application (which
is en masse what a conformance statement is).

> > Is there a category for processors which convert stuff *to* 
> conforming DITA documents? 

> There isn’t such a category now.  We could
add one or we could 
> expand the existing source to source transformer category to include
> non-DITA to DITA source transformers.  I guess the question we
need 
> to answer is are there going to be any requirements that are 
> specific to the non-DITA to DITA transformers or will the same 
> requirements apply as apply for DITA to DITA source transformers?

Or is it better to define categories for DITA-to-X
transformers and X-to-DITA transformers, and transformers which happen
to be DITA-to-DITA get to be both?  A DITA conformance requirement
won't care about what X is, be it XML, or C source, or English prose.

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