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: 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 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