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

> 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

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