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] Re: Strawman Draft of General Conformance Specification

"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

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