[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita-adoption] DTD shell generation tool
During today's DITA TC meeting, I was asked to bring this action to the Adoption TC:New ITEM: Domain Integrator
* http://lists.oasis-open.org/archives/dita/200910/msg00129.html (Kimber)> Eliot clarified that he was following up on the general action from a meeting
> several weeks ago for folks to test-drive the tool. Eliot found that the tool
> comes close to meeting the needs of providing a shell creating tool. Positive
> assessment from Eliot.
> Don reminded the TC members to test-drive the tool.
> Eliot noted that the tool only supports creating a shell from the standard
> modules. There is no support for supporting specialized modules.
> Don asked Eliot to engage the developer via email. We're not sure whether the
> developer monitors the online bug reporting tool.> ACTION: DITA Adoption TC to add the tool to their list of DITA supporting
> tools and write a white paper to help users generate custom shells. Gershon
> to forward this request to the Adoption TC.Here is the content of Eliot's email, linked above:*** START OF EMAIL DUMP***I tried the domain integrator: http://www.elovirta.com/dita-generator/It worked pretty well and is definitely very close to a complete solution.
It constructed what appeared to be a correct and complete shell DTD based on
my selections. It's probably sufficient as it currently exists to enable
creation of shells that reflect the standard modules. The tool did not
appear to provide a way to easily add support for non-standard modules (see
below).The tool itself is implemented in Python, which works well for a Web-based
tool but is less idea for a standalone utility. To create a standalone
utility I would want to reimplement it as a Java application to make it
easier to create a completely standalone application.For the tool to be completely functional it would need to integrate with a
Toolkit instance so that you could deploy additional Toolkit plugins that
provide new vocabulary modules and then use those modules in new shells. The
Toolkit already provides a complete infrastructure for managing non-standard
modules so there's no need to reimplement that functionality.I would see such a tool as ideally being able to take Zip files containing
Toolkit plugins, deploy them to its configured Toolkit instance, and then
letting you include those newly-deployed modules in new shells.The main comment I had for the tool as provided above was to allow the
option of using URNs or URLs for public IDs for shells since not everyone
uses formal public identifier syntax for DTDs.Cheers,Eliot*** END OF EMAIL DUMP ***JoAnn or I will add this to a future Adoption TC meeting.Regards,Gershon
Technical Leader, Engineering
Product Development Services
Phone: +972 9 892-7157
Mobile: +972 57 314-1170
Cisco Systems, Inc.
Cisco home page
Think before you print. This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.
Cisco Systems Limited (Company Number: 02558939), is registered in England and Wales with its registered office at 1 Callaghan Square, Cardiff, South Glamorgan CF10 5BT