[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Minimum required module support for non-specialization-aware processors
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]