Re: Strawman Draft of General Conformance Specification

[Deborah_Pickett@moldflow.com]

> The document named Strawman Draft
of General Conformance Specification
> (conformance_1_2_wek.html) has been submitted by Don Day to the OASIS
> Darwin Information Typing Architecture (DITA) TC document repository.

My comments:

I see some implementations that are
self-proclaimed to be DITA-conformant, but have extremely poor support
for maps.  As a one-time user of such software, I would have appreciated
knowing this ahead of time.  I would like to have some kind of conformance
statement that the creators of the software can't weasel out of.  I
don't know if the right approach is to list Required modules, or Required
shells. If modules, perhaps each module lists the things that it Requires,
so an implementation can be map-conformant but not bookmap-conformant.
 I don't know if or where such a statement should appear in the conformance
section.

I would be upset if a DITA editor could
read my specialized documents only by generalizing them back to topic (especially
if it did not respecialize them on save).  At the moment I don't see
any rules that forbid that.

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.

The conformance requirements of information
management systems seem to be so lax that a file system would almost pass
the test.  Without additional statements on individual DITA features
(e.g., "an href must refer to an existing DITA document, and the fragment,
if any, must match an ID in that document") I can see this being abused
by generic XML databases and other things that don't deserve the DITA stamp
of approval.

Is there a category for processors which
convert stuff *to* conforming DITA documents?  This would apply to
tools like doxygen, which produces machine-generated documentation of software
APIs from comments in the source.  doxygen doesn't do DITA, but oh
if it could...

I'm quite happy with the rest of the
document.

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