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

 

  
  

    
      
        
        

          

        

          
            
Gershon 
            Joseph
Technical Leader, 
            Engineering
Product Development 
            Services


Phone: 
            +972 9 892-7157
Mobile: +972 57 
            314-1170

          
            
Cisco 
            Systems, Inc.

Israel
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