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] | [Elist Home]


Subject: DOCBOOK-APPS: Re: conditionalization of XML


Daniel Veillard <veillard@redhat.com>:
>  Probably 1.0.22 usually within one month.

Thanks.
 
>   Honnestly 1/ and 2/ are not acceptable. Now if someone decides
> to standardize something like <?if?> then it's a big mess.
> Moreover if this can be done by a small and fast external preprocessing,
> why try to put everything in the same tool ? 

Because the external tool can't chase conditionals in entity inclusions.
The conditionals would have to be interpreted at parsing time
for that to work.
 
> > (3) You add --error-filename.  Has the advantage that it could be used
> >     with other preprocessors.
> 
>   Basically the problem is that the processor working on a processed
> file gives back the error in terms of the processed file filename and
> line number instead of the original one. I can hardly see how it could
> be otehrwise, the line number will be wrong anyway and even attempting
> to provide the initial filename is only a partial solution due to the
> entities support problem.

In previous mail, I wrote: "Half the problem is already solved.  There
was a mis-bug in sgmlpre that it passes through newlines from sections
that are conditionalized out.  Thus the line numbers are correct."
Perhaps I didn't make clear that xmlpre inherited this feature.

What would you consider a complete solution to this problem?  I'm not
wedded to xmlif itself, I just need to get some work done that
requires being able to conditionalize stuff.  If you think there's a
better way to handle this, I'm open to it.

So far, Jirka's stylesheet solution fails because of deficiencies in XSLT 1.0,
and xmlif can't chase inclusions.  It sure looks to me like a "complete"
solution will have to be built into xsltproc.

>   Who else is gonna use this switch ? I could try to hack this but this
> sounds partial solution and not of widespread use, right ?

Any other preprocessor would need it.

>   Can't you just sed the output in case of errors ?
>     s/^processed/orgiginal/
> of the stderr stream doesn't sound hard to setup ...

Fine if I'm processing errors in batch mode, yes.  But I mentioned Emacs
for a reason...
-- 
		<a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>


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


Powered by eList eXpress LLC