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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

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

Subject: Re: DOCBOOK: Re: RELAX NG and DocBook

Norman Walsh <ndw@nwalsh.com> writes:

> / Michael Smith <smith@xml-doc.org> was heard to say:
> | Elliotte Rusty Harold <elharo@metalab.unc.edu> writes:
> | > I'm not that familiar with Relax. Can it handle the entity
> | > declarations DocBook needs?
> [...]
> | But I think most or all of the parameter entity reference in the
> | DocBook DTD can be handled in a RELAX NG schema using the RELAX NG
> | <externalref> element and "named patterns" (using the <define> and
> | <ref> elements) as discussed in the RELAX NG tutorial:
> Yeah, I don't think it's PEs that are at issue. Those are mostly
> invisible to the end user. General entities are the problem.

Ah, I did actually think the question was probably about the PEs,
since there's so many of them in the DTD, and the issue of not being
able to declare general entities would be a problem with any schema,
not just DocBook.

I was thinking the ISO character entities at least could be turned
into elements, but then realized that -- because they'd have to valid
anywhere in a document instance -- if they were made elements, and you
were using a validating editor, wanted to insert a new element into
you document, and pulled down a menu or did a completion to see which
elements were valid, you'd be presented not just with a list of the
"real" elements valid at that point, but also with a bazillion ISO
"entity" elements, every time.

I know the workaround is to reference the entities in an internal DTD
subset in your document instances, like this:

  <!DOCTYPE book [
    <!ENTITY % dbcent
     PUBLIC "-//OASIS//ENTITIES DocBook XML Character Entities V4.1.2//EN"
     %dbcent; ]

...and you could do the same thing for any custom general entities you
want to declare. But that seems like an less-than-elegant solution.


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

Powered by eList eXpress LLC