dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: DTD shell generation tool
- From: "Gershon Joseph (gerjosep)" <gerjosep@cisco.com>
- To: <dita-adoption@lists.oasis-open.org>
- Date: Tue, 3 Nov 2009 12:09:49 -0800
During today's DITA
TC meeting, I was asked to bring this action to the Adoption
TC:
> 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***
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
gerjosep@cisco.com 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 | |
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]