[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK-APPS: Re: conditionalization of XML
On Fri, Oct 11, 2002 at 08:52:01AM +0100, Tim Waugh wrote: > On Thu, Oct 10, 2002 at 05:43:38PM -0400, Daniel Veillard wrote: > > > > (1) You add support for ?if? and friends to xsltproc. Probably the > > > fastest route to a complete solution. > > > > > > (2) You tell me you'll take a patch from me to implement them. I'd > > > have to learn the xsltproc code, so it would take longer, but I > > > can do that. > > > > 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 ? > > Eric has written a tool, xmlif, to do this, and it's available in > xmlto-0.0.11pre6. What's a 'big mess', incidentally? Do 'if' et al > need to be namespaced, you mean? Well something like this, basically I believe in standardization, don't blame me on this but I would dislike if people were starting to rely on xsltproc specific behaviour, if that behaviour isn't properly documented and has a sufficiently large user base. Been there, even when conceptually something looks like a very simple tool, it's only when you go through the steps of a large review that you discover the potentially fatal flaws that can be associated with it. As a programmer I prefer to write and maintain code associated to processing which went at least through the first steps equivalent to a standardization track, coding is slow, maintainance is a pain, life is short, enough reasons to be relatively careful about what I decide to implement and maintain. Now to be relatively specific about <?if?> as much as I can since I don't have any clear picture of how the selection is actually done, it seems to be in the line of the previously found standard extention abuses like #pragma foobar for Winblows C compilers or various custom PI that each SGML toolchains seems to have developped to tie in their customers in the 90's (I may get some heat for this, I don't care ;-) I would really prefer to get DocBook fixed to allow proper conditionalization at the *markup* level (if the current solution is not sufficient for users' needs like Eric), which then will be close to trivial to handle correctly in the existing XSLT tools, independantly of the toolchain used. In a nutshell, my guts feeling is that PIs + custom preprocessing are the kind of patchy' mechanism which would be acceptable if the environment was a locked proprietary toolchain but don't feel right in a DocBook framework where most of the processing is done otherwise with standard tools. Now if a number of people did voice in saying that's the kind of processing they really need, that there is a clean and public description with review of the suggested extension, then I would certainly be an early implementor of said feature. Makes sense ? Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC