Changed the command line arguments

[Chris Maloney]

I would like to change the invocation of the main program, and I documented my proposed changes in the README on github (just scroll down to "Usage" here:  https://github.com/Klortho/DtdAnalyzer).  What do you guys think?  The main change is to allow the user to specify the DTD with a system id or public id, instead of needing a stub XML file.  It should be easy, shouldn't it?  Other than that, it's just a change to using "--opt" to introduce each option (except output) and making the XSLT optional.

Is it okay?  Can we document this in the paper this way?  

If so, can we come up with similar usage pattern for three new scripts:

- dtddocumentor:  which should really just be an alias for dtdanalyzer with an implicit "--xstl dtddocumentor.xsl", I'd think

- dtdcomparator:  needs to specify two dtds, not just one.

- dtdschematronator (?): generate schematron; again, same as dtdanalyzer but with an implicitly specified xslt, right?

- Did I miss any?

These names are clunky, I know -- any other suggestions?  I made them a little long and clunky so as to make sure they're unique on an average unix system, but there might be better choices.

Chris

[Demian Hess]

Yes, that seems perfectly reasonable. It would be easy enough to create a fake in memory SAX source that we feed to the parser. Saves the pain of making those stubby driver XML files.

I'm leery of hard coding the -dtddocumentor , -schematronator, etc. into the app. I prefer getting the "meta" xml representing the DTD so that I can manipulate it myself and feed it into other processes. Or having the option to specify an XSL that should be applied immediately by the app.

Code there be a -xsl option that lets you apply the XSL and send to -out location you specify? Plus a -meta option (or something like that) that generates just the XML and sends to the -out location?

Note that in the past w/the DataDictionaryApp, I would get the "meta" XML by passing in an XSL that just have an <xsl:copy-of select="."/> rule.

Chris

--
You received this message because you are subscribed to the Google Groups "DtdAnalyzer" group.
To post to this group, send email to dtdan...@googlegroups.com.
To unsubscribe from this group, send email to dtdanalyzer...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dtdanalyzer?hl=en.

--
Demian Hess

Avalon Consulting, LLC
527 Maple Avenue East, Suite 200, Vienna, VA 22180

Mobile: 301-943-8307
Fax: 845-367-5496
he...@avalonconsult.com

[Chris Maloney]

On Thu, Aug 30, 2012 at 11:22 PM, Demian Hess <he...@avalonconsult.com> wrote:
>
> Yes, that seems perfectly reasonable. It would be easy enough to create a
> fake in memory SAX source that we feed to the parser. Saves the pain of
> making those stubby driver XML files.
>
> I'm leery of hard coding the -dtddocumentor , -schematronator, etc. into
> the app. I prefer getting the "meta" xml representing the DTD so that I can
> manipulate it myself and feed it into other processes. Or having the option
> to specify an XSL that should be applied immediately by the app.

I wasn't suggesting hardcoding those tools' functionality into the Java app.
I'm suggesting that we write shell scripts for those, and include them in
the scripts directory. The "dtdanalyzer" itself is a shell script. I realize
now you were probably thrown off because I used hyphens for bullets,
and maybe it made them look like command-line options.

>
> Code there be a -xsl option that lets you apply the XSL and send to -out
> location you specify? Plus a -meta option (or something like that) that
> generates just the XML and sends to the -out location?

I don't understand you exactly. I'm suggesting that the output of the tool
always goes either to the output you specify, or to stdout, if you don't
specify anything. If you give --xslt <xsl file>, then it will first pipe its
normal output through the given XSLT (as it does now) and then write
it to the output file or to stdout. I don't understand what this "--meta"
would do.