OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[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"

(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.


Michael Smith


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]