[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Tool to query dtd/schema for valid element children|attributes [SOLVED]
David Nebauer <davidnebauer@switch.com.au> writes: > It surely does. Out of the three tools you pointed out, this one runs > the fastest. Blisteringly so, in fact. As with everything, however, > there is a trade-off -- the minimum possible output size is double that > of flatten running in default mode. hmm, I believe that is in part because it is expanding all the content models (that is, replacing all parameter entities with what they expand out to). There seems to be no way to prevent it from doing that (the --output-pe-decls option appears not to prevent it at least). Using the --strip-comments option will make it a bit smaller, though. If it provided an option for keeping the PEs as-is, I think it would output a file just as small as what flatten does. > >And it can handle entities that have system IDs with remote URIs. > > Not on my system, it couldn't: > ------------------------------------------------------------------------------------------------------- > $ java -jar dtd-flatten.jar > http://oasis-open.org/docbook/xml/4.2/docbookx.dtd [...] > Public IDs are misinterpreted as command-line options: > ------------------------------------------------------------------------------------------------------- > $ java -jar dtd-flatten.jar "-//OASIS//DTD DocBook XML V4.2//EN" > Unrecognized option '-//OASIS//DTD'. Actually, what I meant was that it could handle remote system IDs that occur within a DTD. That is, if you have something like this: <!ENTITY % docbook.dtd PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"> %docbook.dtd; (Which is what you'd have in a DocBook DTD customization layer.) I didn't mean that it supported specifying remote URIs or public IDs on the command line. > Thanks for all your help, Michael. The combination of xmlcatalog (using > the public ID!) and either of these tools will enable me to solve the > coding problem I have. Great! But I am reminded that it sure would be nice to have a Perl interface to the catalog stuff in libxml2. The current Perl bindings (libxml-libxml-perl package in Debian) don't provide it. --Mike -- Michael Smith http://sideshowbarker.net/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]