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

"Ogden, Jeff" <> 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