Norman Walsh <[EMAIL PROTECTED]> writes: > / Michael Smith <[EMAIL PROTECTED]> was heard to say: > | The only problem I've run into is in using the DTD with Earl Hood's > | perlSGML. If I try to run the perlSGML 'dtdview' command on it, I get: > | > | $ dtdview docbookx.dtd > | Reading catalog(s) ... > | Reading docbookx.dtd ... > | Syntax error in subset. > | Unexpected character: "E", ascii code=69. > | Reason: > | Invalid character found outside of a markup statment > | > | What it's complaining about is the line starting with "ERROR" in: > | > | <![%sgml.features;[ > | <![%xml.features;[ > | ERROR: Exactly one of xml.features and sgml.features must be turned on! > | ]]> > | ]]> > > Hmmm. That's interesting. His tool is obviously ignoring marked > section boundries,
I think maybe the only thing it can't handle is character data in marked sections. It seems to handle the other marked sections in the DTD correctly. > but because we have a single driver for SGML and XML, I've set > things up so that it is explicitly an error to have both > xml.features and sgml.features turned on simultaneously. > > I don't know if we should fix this or not. > > Pro: tools that ignore MS boundries wouldn't get confused. > Con: turning both sets of features on might result in unpredictable behavior I think it definitely should be an error to have both turned out simultaneously. But we could wrap the error text in a comment: <![%sgml.features;[ <![%xml.features;[ <!-- ERROR: Exactly one of xml.features and sgml.features must be turned on! --> ]]> ]]> Would that be acceptable? I realize it's kind of a hack, but it keeps dtdview from complaining at least. We do have the precedent of a similar sort of workaround to get the DTD to work with not-fully-compliant parsers: the definitions for the various redeclaration placeholders (rdbhier, etc.) -- the places marked with the comments like: <!-- Defining rdbhier here makes some buggy XML parsers happy. --> --Mike
