RE: [dita] Minimum required module support for non-specialization-aware processors

["Ogden, Jeff" <jogden@ptc.com>]

My take on this is that you can't impose any minimum required module
support.  I think this has to work the way a lot of things in the DITA
standard work, that implementers need to say that they do and don't
support.  If they aren't specialization aware and they say they only
support a specific list of DITA topic and map document types, I think
that that has to be allowed as long as the documents produced are DITA
conforming.  Or course such an implantation won't meet many people's
needs and those people won't choose to use it, but that in and of itself
shouldn't make something non-DITA conforming.

Here is an example:

Image Acme Aircraft Support, Inc. which makes a DITA aware S1000D Editor
that supports one specialized map document type, AcmeS1000DMap, and
several specialized topic document types, AcmeS1000DTopic1,
AcmeS1000DTopic2, ....  The Acme Editor will only read and write these
document types. It does not process regular DITA maps or topics.  The
Acme documents are all DITA conforming and can be exchanged with other
organizations with or without generalization.  I think the Acme Editor
can claim to be DITA conforming.

    -Jeff

> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com]
> Sent: Monday, January 18, 2010 12:50 PM
> To: dita
> Subject: [dita] Minimum required module support for
non-specialization-
> aware processors
> 
> In trying to rework the conformance topic to be more crisp and more
> understandable, I wrote this statement:
> 
> "A DITA-aware processor is a conforming DITA processor if it
implements
> all
> required processing relevant to that processor for all element types
> defined
> in the core DITA map, topic, concept, task, and reference vocabulary
> modules."
> 
> My reasoning was that conforming non-specialization-aware DITA 1.0
> processors should continue to be conforming, so the minimum
> implementation
> requirements should reflect the standard modules provided with DITA
1.0.
> 
> Is that a reasonable statement?
> 
> Would there be a reason to require non-specialization-aware processors
> to
> build in support for more than the base modules?
> 
> Because specialization-aware processors can provide *some* useful
> processing
> for all specializations, standard or not, there's no need to require
> them to
> provide module-specific processing for all modules.
> 
> But a non-specialization-aware-but-DITA-aware processor can only
> provide
> reliable processing for those modules for which they have built in
> processing based on element type names.
> 
> This also suggests that there is, in DITA 1.x, a base "DITA core" that
> includes concept, task, and reference. I don't know that we've made
> that
> notion explicit, but the conformance statement seems to require that
we
> do
> in order to be able to say something sensible about conforming
> non-specialization-aware processors.
> 
> The other option would be to require specialization awareness for
> conforming
> processors, but I think that would potentially disenfranchise tools
> that are
> architecturally incapable of direct specialization awareness, such as
> FrameMaker.
> 
> Cheers,
> 
> Eliot
> 
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 610.631.6770
> www.reallysi.com
> www.rsuitecms.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php