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: [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]