[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] constraints support? (Was: Problems with the task model)
On 9/11/09 2:09 PM, "JoAnn Hackos" <joann.hackos@comtech-serv.com> wrote: > Thanks, Su-Laine, > > You've provided a very good analysis and suggested rewordings to clarify > the situation. I still have a problem, of course, with the assumption > that constraints are "easy" to implement and with the confusion about > providing both task models, carefully named, in the "out of the box" > editor solutions. They are "easy" to implement to the degree that: 1. They use existing standard DTD and XSD syntax 2. The implementation pattern for them is straightfoward and well-defined in the 1.2 spec 3. Implementation is a mechanical process given a clear definition of what the desired constraints are (in the sense that you need only follow the general coding rules for constraint modules and you will arrive at a working solution--there is no invention or conceptual synthesis required). 4. Integrating a constraint module into a DTD or XSD shell is no more involved than integrating a domain module, so by that measure it is exactly as easy (or hard) to implement as a domain module. In practice, once a person knows how to bang out the right syntax, it should literally take minutes to implement a specific constraint module and integrate it with a doctype shell. Of course, you still need to have a working knowledge of DTD or XSD syntax, so this is not an end user task, but it's a task that can be learned by anyone. And as for shell DTD creation, it should be possible to largely or completely automate the creation of constraint modules, at least for simple constraints (e.g., removing specific types from repeating OR groups or simple sequences). I will also mention again, as I have in the past, that there is no *technical* reason that editing tools need require any more configuration than simply providing the appropriate entity resolution catalog in order to use any conforming shell or specialization, as long as they are fully specialization aware. OxygenXML demonstrates this by requiring only the ability to resolve references to DTD components, which can be done by the simple process of putting your shells and modules into one or more Toolkit plugins and deploying them to the Open Toolkit integrated with Oxygen. Tools like Arbortext Editor and XMetal have been designed around a more controlled approach to configuring and deploying doctypes, which is fine, but that control does add one or two steps to the deployment process. But even there, it's not a lot of extra effort. Framemaker, because it is currently not specialization aware (or even specialization capable because EDDs cannot do style binding based on attribute values alone), requires the most effort, because you have to create or generate an EDD for each different shell you want to use, but even there, that process could be (and I think has been) automated. Cheers, Eliot ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]